Message-ID: <3928A8E8.BF7343BD@mtu-net.ru> Date: Mon, 22 May 2000 07:26:32 +0400 From: "Alexei A. Frounze" X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: ru,en MIME-Version: 1.0 Newsgroups: comp.os.msdos.djgpp Cc: djgpp AT delorie DOT com Subject: Re: C++, complex, etc References: <3923BA11 DOT AD387617 AT mtu-net DOT ru> <8g15d8$nl9$1 AT news01 DOT cit DOT cornell DOT edu> <39242D85 DOT 6A95D430 AT mtu-net DOT ru> <8g23d1$6qp$1 AT news01 DOT cit DOT cornell DOT edu> <3924E744 DOT 748FFFEC AT mtu-net DOT ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Recipient: djgpp AT delorie DOT com Reply-To: djgpp AT delorie DOT com Damian Yerrick wrote: > > On Fri, 19 May 2000 11:03:32 +0400, "Alexei A. Frounze" > wrote: > > >"A. Sinan Unur" wrote: > >> the problem with casting an object of type size_t to int is the same as the > >> problem with casting an unsigned int to char. sure enough there may be > >> platforms where you don't loose any information in the process, but it is > >> not safe. what if size_t is 64 bits and int is 32 bits? casting how can > >> casting size_t to int be safe (even disregarding the sign issue, which is > >> bad enough). > > > >Suppose we have a string. If the string is definetely shorter than INT_MAX > >and SSIZE_MAX (say less than 32000 characters), there must be everything > >okay with type casting for strlen(), strncpy(), etc. > > But if your string contains the full text of Carlo Collodi's _The > Adventures of Pinocchio_ (loaded from the Project Gutenberg etext), > and you're on a 16-bit system, things start to break down. Can you > say "buffer overflow"? In such a situation I would read it character by character and refer to feof(). ;)) bye. Alexei A. Frounze ----------------------------------------- Homepage: http://alexfru.chat.ru Mirror: http://members.xoom.com/alexfru