Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: bart Newsgroups: comp.lang.c Subject: Re: Suggested method for returning a string from a C program? Date: Thu, 20 Mar 2025 14:00:29 +0000 Organization: A noiseless patient Spider Lines: 73 Message-ID: References: <868qp1ra5f.fsf@linuxsc.com> <20250319115550.0000676f@yahoo.com> <20250319201903.00005452@yahoo.com> <86r02roqdq.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 20 Mar 2025 15:00:30 +0100 (CET) Injection-Info: dont-email.me; posting-host="b23726e8530270bdb8279be50ba9c02e"; logging-data="3520642"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX189+XYJJAbG0X6XucJB+TRQ" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:K9Xn6Q4Jcd7r61l8oBCS4m5a6hw= In-Reply-To: Content-Language: en-GB Bytes: 4069 On 20/03/2025 13:36, Scott Lurndal wrote: > bart writes: >> On 20/03/2025 12:09, Tim Rentsch wrote: >>> Michael S writes: >> >>>> I suspected that, but was not sure, so suggested to DFS a type that I am >>>> sure about. >>> >>> The width of char and [un]signed char must be at least 8 bits. >>> The width of [un]signed short must be at least 16 bits. >>> The width of [un]signed int must be at least 16 bits. >>> The width of [un]signed long must be at least 32 bits. >>> The width of [un]signed long long must be at least 64 bits. >>> >>> That should be easy enough to remember now. >> >> That table suggests that any program mixing 'short' and 'int' is >> suspect. If 'int' doesn't need to store values beyond 16 bits, then why >> not use 'short'? >> >> 'long' is another troublesome one. If the need is for 32-bit values, >> then it's surprisingly rare in source code. > > Long is useless, because Microsoft made the mistake of defining > 'long' as 32-bits on 64-bit architectures, while unix and linux > define it as 64-bits. Unix and Linux define it as 32 bits on 32-bit architectures and 64 bits on 64-bit ones. > So long can't be used in programs intended to be portable to > other operating systems. As defined by Unix/Linux, long is not portable between different Unix/Linux OSes if they run on a different architecture. As defined by Microsoft, long is portable between Windows OSes even on different architectures. 'long long' is defined as a 64-bit > type in both Windows and Linux. > > Using the defined width types is far better (e.g. uint64_t); > even if the standard allows the type to not exist on a particular > implementation. No useful implementation would fail to define > uint64_t in these modern times. The point was made earlier on that int64_t types are awkward to work with; they need that stdint.h header to even exist, and they need those ugly macros in inttypes.h to print out their values. This is why it popular to just do: typedef long long int i64; and to use %lld to print, and -LL on literals to force a 64-bit type. stdint.h et al are just ungainly bolt-ons, not fully supported by the language. The problem with 'long' manifests itself there too, since on Linux, 'int64_t' appears to be commonly defined on top of 'long' for 32-bit systems, and 'long long' for 64-bit ones. So somebody eschewing those ugly macros and using "%ld" to print an 'int64_t' type, will find it doesn't work when run on a 64-bit system, where "%lld" is needed. Same problem with using '1L' to define an int64_t literal.