Path: ...!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: Waldek Hebisch <antispam@fricas.org>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 9 Sep 2024 16:21:11 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vbn79l$2g9i6$1@paganini.bofh.team>
References: <vab101$3er$1@reader1.panix.com>   <vbcs65$eabn$1@dont-email.me> <vbekut$1kd24$1@paganini.bofh.team> <vbepcb$q6p2$1@dont-email.me> <vbgb5q$1ruv8$1@paganini.bofh.team> <vbhbbb$1blt4$1@dont-email.me> <vbipp5$24kl5$1@paganini.bofh.team> <vbk0d9$1tajm$1@dont-email.me> <vbkpfc$27l2o$1@paganini.bofh.team> <vbl3am$228vv$1@dont-email.me> <vblfgb$2dkij$1@paganini.bofh.team> <878qw13a40.fsf@nosuchdomain.example.com> <vbll6l$2dpn7$2@paganini.bofh.team> <874j6p34df.fsf@nosuchdomain.example.com>
Injection-Date: Mon, 9 Sep 2024 16:21:11 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="2631238"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 5209
Lines: 82

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Waldek Hebisch <antispam@fricas.org> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Waldek Hebisch <antispam@fricas.org> writes:
>>>> Bart <bc@freeuk.com> wrote:
>>> [...]
>>>>> I had a problem with this code because it was so verbose. The first 
>>>>> thing I did was to define aliases u64 and u32 for those long types:
>>>>> 
>>>>>  typedef unsigned long long u64;
>>>>>  typedef unsigned long u32;
>>>>
>>>> This code runs in 33 bit i386, 32 bit ARM and 64 bit x86-64, in
>>>> all cases under Linux.  As Keith noticed, most popular of those
>>>> has 64-bit long.  So your definition would break it.  You need
>>>>
>>>> typedef unsigned int u32;
>>> 
>>> Just add #include <stdint.h> and use uint32_t -- or, if you value
>>> brevity for some reason:
>>> 
>>>     typedef uint32_t u32;
>>> 
>>> (Bart dislikes <stdint.h>, but there's no reason you should.)
>>
>> 1. Well, I used to care about pre-Ansi compilers and for benefit
>> to them I got into habit of avoiding <stdint.h>.  Yes, it is time
>> to change and on microcontrollers I use <stdint.h> as sizes
>> are important there and I do not expect to ever compile
>> microcontroller code with non-Ansi compiler.
> 
> Pre-ANSI?  I haven't been even been able to find a working pre-ANSI
> C compiler.

At least in 1994 HP shipped their base system with pre-Ansi compilers.
I heard that this practice continued for some time and also that
some other vendors did it.  Hardware were pretty reliable, so could
be used for very long time.  I think that few years ago, if I wished
I could get HP machine running and use its pre-ANSI compiler.

In more general terms, some developers seem to think that their moral
duty is to break any software that is 4 years old or more.  I have
quite different view: if feel that breaking 10 years old or even 20
years old system requires compeling reason.  And in my judgement
reason frequently are not compeling enough.
 
> <stdint.h> was added in C99, so a C89/C90 ("ANSI") implementation might
> not support it, but I'd still be surprised if you could find a C
> implementatation these days that doesn't have <stdint.h>.  And you can
> roll your own or use something like
> <https://www.lysator.liu.se/c/q8/index.html>.

Well, recently I had trouble with sofware that used C99 feature.
On some my Linux systems gcc default was gnu+C90 and it refused the
C99 features.  That was resolvable, but broke automated build and
required manual intervention to add appropriate option to gcc.
For "normal" users on such Linux sotware was "broken".  '<stdint.h>'
is not affected by such issue, but in general I would like a
monkey to be able to compile my code on wide variety of system.
As my ability to test different scenarios is limited, I tend
to be consevative in features that I use (OK, that is personal
judgement, in several cases I depend in gcc feature, but I feel
that I have reasons to depend on such features).

>> 2. As I explanined fixed size is just current state of developement.
>> On 64-bit machines code should use bigger types.  And to get
>> 128-bit type it seems that I need nonstandard type (there seem
>> to be new types in C23, but I did not investigate them deeper).
> 
> C23 doesn't add any new support for 128-bit integers.
> 
> gcc (and compilers intended to be compatible with it, like clang)
> support __int128 and unsigned __int128 types, but only on 64-bit
> systems, and they're not strictly integer types (for example, there are
> no constants of type __int128).

Yes, I know that.  IIUC clang supports bigger types, and in one
of drafts I found "bit exact integer types".  At first glance it
looked that they could support bigger lengths than standard integer
types.

-- 
                              Waldek Hebisch