Re: Hex string literals (was Re: C23 thoughts and opinions)

From	Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups	comp.lang.c
Subject	Re: Hex string literals (was Re: C23 thoughts and opinions)
Date	2024-06-17 17:19 -0700
Organization	None to speak of
Message-ID	<87cyof14rd.fsf@nosuchdomain.example.com> (permalink)
References	(16 earlier) <874jahznzt.fsf@nosuchdomain.example.com> <v36nf9$12bei$1@dont-email.me> <87v82b43h6.fsf@nosuchdomain.example.com> <87iky830v7.fsf_-_@nosuchdomain.example.com> <v4p0dv$jeb2$1@dont-email.me>

Show all headers | View raw

David Brown <david.brown@hesbynett.no> writes:
> On 17/06/2024 01:48, Keith Thompson wrote:
[...]
>                                                            For binary,
> the compaction is irrelevant and indeed counter-productive - binary
> literals became a lot more practical with the introduction of digit
> separators. (For standard C, these are from C23, but for C++ they came
> in C++14, and compilers have supported them as extensions in C.)

I forgot about digit separators.

C23 adds the option to use apostrophes as separators in numeric
constants: 123'456'789 or 0xdead'beef, for example.  (This is
borrowed from C++.  Commas are more commonly used in real life,
at least in my experience, but that wouldn't work given the other
meanings of commas.)

I briefly considered that, for consistency, we might want to
use apostrophes rather than spaces in hex string constants:
0x"de'ad'be'ef".  But since digit separators are purely decorative,
and spaces in my proposed hex string literals are semantically
significant (they terminate a byte), I'll stick with spaces.

You could even write 0x"0 0 0 0" to denote 4 zero bytes (where
"0x0000" is 2 bytes) but 0x"00 00 00 00" or "0x00000000" is probably
clearer.

I think allowing both spaces and apostrophes would be too confusing.

>> Octal
>> string literals 0"012 345 670" *might* be worth considering.
>
> Most situations where octal could be useful died out many decades ago
> - it is vastly more likely that "012" is intended to mean 12 than 10.
> No serious programming language supports a leading 0 as an indication
> of octal unless they are forced to do so by backwards compatibility,
> and many that used to support them have dropped them.
> 
> Having /some/ way to write octal can be helpful to old *nix
> programmers who prefer 046 to "S_IRUSR | S_IWUSR | S_IRGRP" in their
> chmod calls. (And to be fair, the constant names made in ancient
> history with short identifier length limits are pretty ugly.)  But it
> is not something to be encouraged, and I think there is no simple
> syntax that is obviously octal, and not easily mistaken for something
> else.

There is, the proposed "0o" prefix.  It's already supported in both Perl
and Python, and likely other languages.

>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3193.htm>
>> proposes a new "0o123" syntax for octal constants; if that's adopted,
>> I propose allowing 0o"..." and *not" 0"...".  I'm not sure whether
>> to suggest hex only, or doing hex, octal, and binary for the sake
>> of completeness.
>
> Binary support is useless, and octal support would be worse than
> useless - even using an 0o rather than 0 prefix.  Completeness is not
> a justification for repeating old mistakes or complicating a good idea 
> with features that will never be used.

I like binary integer constants (0b11001001), but I suppose I
agree that they're not useful for larger chunks of data.  I have no
problem supporting only hex string literals, not binary or octal --
but I'd have no problem with having all three if anyone thinks that
would be sufficiently useful.

>> What I'm trying to design here is a more straightforward way to
>> represent raw (unsigned char[]) data in C code, largely but not
>> exclusively for use by #embed.
>
> Personally, I'd see it as useful when /not/ using #embed.  I really do
> not think programmers will care what format #embed uses.  I don't
> share your concerns about efficiency of implementation, or that
> programmers need to know when it is efficient or not.  In almost all
> circumstances, C programmers never see or need to think about a
> separation between a C preprocessor and a post-processed C compiler -
> they are seen as a single entity, and can use whatever format is
> convenient between them.  And once you ignore the implementation
> details, which are an SEP, the way #embed is defined is better than a
> definition using these new hex blob strings.

I think my main problem with the current #embed is that it's
conceptually messy.  I'm probably an outlier in how much I care about
that.

It's not clear whether the problems with the current definition of
#embed are as serious as I suggest; you clearly think they aren't.  But
even if the current #embed is ok, I think adding hex string literals and
adding a language defined embed parameter that specifies using hex
string literals rather than a list of integer constant expressions would
be useful.  Among other things, it lets the programmer specify that a
given #embed is only to be used to initialize an array of unsigned char.

For example, given a 4-byte foo.dat containing bytes 1, 2, 3, and 4:
    const unsigned char buf[] = {
        #embed "foo.dat"
    };
would expand to something like:
    const unsigned char buf[] = {
        1, 2, 3, 4
    };
(and the same if buf is of type int[] or double[]), while this:
    const unsigned char buf[] =
        #embed "foo.dat" hex(true) // proposed new parameter
    ;
would expand to something like:
    const unsigned char buf[] =
        0x"01020304"
    ;
(and would result in an error if buf is of type int[] or double[]).

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-14 14:30 -0700
  Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-14 23:39 +0100
    Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-15 19:17 +0200
      Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-15 20:27 +0100
        Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-15 22:39 +0000
          Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-16 00:20 +0100
            Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-16 01:16 +0000
            Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-16 12:31 -0700
              Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-17 00:03 +0000
        Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-16 16:54 +0200
          Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-16 20:00 +0100
            Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-17 10:49 +0200
            Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-17 13:18 +0300
  Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-15 17:58 +0200
    Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-15 22:37 +0000
      Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-16 16:55 +0200
  Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 16:48 -0700
    Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-17 11:42 +0200
      Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 17:19 -0700
        Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-18 04:19 +0000
          Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 22:39 -0700
        Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-18 15:54 +0200
          Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 15:00 -0700
            Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-19 09:37 +0200
              Re: Hex string literals (was Re: C23 thoughts and opinions) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-19 10:17 +0000
                Re: Hex string literals (was Re: C23 thoughts and opinions) Michael S <already5chosen@yahoo.com> - 2024-06-19 13:44 +0300
                Re: Hex string literals (was Re: C23 thoughts and opinions) bart <bc@freeuk.com> - 2024-06-19 11:57 +0100
                Re: Hex string literals (was Re: C23 thoughts and opinions) scott@slp53.sl.home (Scott Lurndal) - 2024-06-19 13:46 +0000
                Re: Hex string literals (was Re: C23 thoughts and opinions) Michael S <already5chosen@yahoo.com> - 2024-06-19 18:02 +0300
          Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-19 07:25 +0000
            Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-19 10:49 +0200
              Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-21 07:13 +0000
                Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-21 13:06 +0200
                Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-21 22:48 +0000
                Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-22 13:40 +0200
                Re: Hex string literals (was Re: C23 thoughts and opinions) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-21 10:15 -0400
            Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 02:32 -0700
      Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-18 04:19 +0000
    Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Kettlewell <invalid@invalid.invalid> - 2024-06-17 11:41 +0100
      Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Kettlewell <invalid@invalid.invalid> - 2024-06-17 14:57 +0100
      Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 18:57 -0700
        Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-18 08:12 +0000
        Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Kettlewell <invalid@invalid.invalid> - 2024-06-18 16:14 +0100
    Re: Hex string literals (was Re: C23 thoughts and opinions) bart <bc@freeuk.com> - 2024-06-17 14:21 +0100
      Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 19:20 -0700
      Re: Hex string literals (was Re: C23 thoughts and opinions) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-17 22:39 -0700
        Re: Hex string literals (was Re: C23 thoughts and opinions) Michael S <already5chosen@yahoo.com> - 2024-06-18 12:39 +0300
          Re: Hex string literals (was Re: C23 thoughts and opinions) bart <bc@freeuk.com> - 2024-06-18 11:28 +0100
            Re: Hex string literals (was Re: C23 thoughts and opinions) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 11:12 -0700
          Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-18 17:20 +0200
          Re: Hex string literals (was Re: C23 thoughts and opinions) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 11:04 -0700
          Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-20 06:51 +0000
      Re: Hex string literals (was Re: C23 thoughts and opinions) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-18 09:50 +0000
        Re: Hex string literals (was Re: C23 thoughts and opinions) scott@slp53.sl.home (Scott Lurndal) - 2024-06-18 13:56 +0000
          Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-18 17:21 +0200
            Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-18 19:25 +0100
              Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-18 19:38 +0100
              Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-21 22:49 +0000

csiph-web