Non-constant constant strings

[Keith Thompson]

I cannot help but consider the fact that Google Groups provides a frew
web-based interface which removes shortcomings in the text-based Usenet
group. It allows HTML messages, longer lines with automatic wrapping,
immediate access to many groups, complex searching, and more.

It provides an interface to an existing text-based medium, an interface
that encourages posting of messages that do not work in that medium.

Web-based interfaces are fine. Google Groups is just a bad one.

[...]

 

[Ben Bacarisse]

I cannot help but consider the fact that Google Groups provides a frew
web-based interface which removes shortcomings in the text-based Usenet
group. It allows HTML messages, longer lines with automatic wrapping,
immediate access to many groups, complex searching, and more.

As it happens I don't want HTML messages but that might be historical.
Of the others the only one I don't have is search, and Google has sadly
broken their search function. It is now almost useless for finding
specific posts.

It seems that the future may be speaking, in an attempt to bring Usenet
into the 2010s and beyond.

Text-based interfaces were nice ... they used the technology available at
the time (limited disk space, limited memory, slower clock speeds). But
the technology of the 2010s is significantly beyond anything we've had
previously. Most modern multi-core CPU desktops with 8+ GB of memory,
1+ TB of disk storage, an average to high-end GPU, have more computing
power than supercomputers did 15+ years ago.

GUIs provide a far better user experience, and are only becoming more
common as time goes on. Smart phones. Tablets. Touch screen. We're
changing our computing needs.

Each to their own, but I find GG's interface to Usenet painful to use.
I am no Luddite -- give me my tablet for reading RSS feeds any day --
but not all new things are better than the old ones.

 

[glen herrmannsfeldt]

(snip on '\r' and '\n')

If C had defined specified sizes for predefined types, then int would
probably be 16 bits and long would be 32 (the sizes they had in early
PDP-11 implementations).

Or perhaps not. The first edition of K&R, the book that defined the
language in 1978, showed int with a size of 16 bits on the PDP-11, 36
bits on the Honeywell 6000, and 32 bits on the IBM 370 and Interdata
8/32. None of those platforms had a 64-bit integer type, because 64-bit
integer arithmitec was not supported on the hardware of the time.

Well, S/370 can add, subtract, 64 bits reasonably easily, also
generate 64 bit products, and divide 64 bit dividends. Many systems
can handle larger products and dividends than others, but rarely
do high-level languages allow for it.

-- glen

 

[Seebs]

Not at all. I presumed "those members" involved in the ANSI
authorizing were a small number, power-seeking representatives of
the entire C language developer base of us "little people," while
the much larger group (developers who were coding in C in general)
contained many developers, and it was many of them who screamed
"WHAT!" and then passed out.

Nope. I was on the committee for a while, not from wanting "power"
but because I was fascinated by standardization, and by and large,
I can report that a LOT of time and effort goes into finding out
what people are doing and expecting to work, and avoiding breaking
anything.

This thread is, I think, the first time I've ever seen someone react
to the information that string literals aren't writeable in a way
that suggests that they think this is a bad idea.

-s

 

[Seebs]

When most people encounter something they are in "learning how it works"
mode. They read and study and come to understand the system. However,
some people look at things differently desiring to understand the philosophy
of why something works. This gives them a different perspective than the
user, as they are more akin to a type of author, desiring to peer into the
inner workings and perform mental optimizations upon the design.

This sounds sort of similar to the "packer/mapper" model sometimes used
to describe the way people model things.

In my experience there are about 20% authors and 80% users in the developer
community. That number falls somewhat to 5% to 10% authors and 90% to 95%
users in certain types of developer houses (more long-term maintenance of
established applications, rather than new shops which are writing new apps).

My personal experience. YMMV.

And yet, you never get around to stating what the relevance of this is. It
sort of comes across as though you intend to express that you are one of
the people who is doing the rare thing that involves a deeper desire to
understand, while the people who don't share your intuition for what string
literals should do are all presumably of the other sort...

-s

 

[Seebs]

Why do we have "void function(void)" when "function()" would work
sufficiently at that level in a source file? It's explicitly so
we convey that no mistake was given as by accidentally leaving out
some parameters. We declare void to indicate "I purposefully
intended to leave this empty, there are no return variables, there
are no parameters," and so on.

The (void) thing is also because of a historical quirk -- K&R function
declarations didn't have prototypes, so () could mean "with unspecified
arguments" rather than "with no arguments".

It's the same here. "Oh, another comma ... was the developer
finished? Was there supposed to be more? What is missing? What
was left out? Please ... I need answers. I'm left hanging in a
state of confusion that is disrupting my soul. Whatever do I do?"

Never had that reaction to it, just because it's such a common way to
simplify the life of people writing code generators.

-s

 

[Kaz Kylheku]

When most people encounter something they are in "learning how it works"
mode. They read and study and come to understand the system. However,
some people look at things differently desiring to understand the philosophy
of why something works.

Then there is a third group: insipid whiners about trailing commas being
allowed for convenience in a language they barely understand.

 

[Öö Tiib]

Most if not all of the programmer's editors I've used on Windows
recognise Unix line endings and gcc on Unix recognises Windows endings.
Text mode is something of a curse!

Not all Unix tools tolerate Windows-style line endings. For example,
if you write:

if [ "$x" = 42 ] ; then
echo ok
fi

in a bash script, and the script file uses Windows-style line endings,
bash will complain that "then\r" is an unrecognized token. (Except that
it will print the "\r" literally, causing a very confusing error
message.)

AFAIK bash will do it on Cygwin as well. Typical solution:

bash -O igncr script_containing_crlf

Blindly using "foreign" format text files on any system is not a good
idea.

The non-programmer users or newbies can edit the files with
whatever editor and supply these to your program as input.
Cryptic error messages caused by BOM or alien line endings is
common headache. Does it help to tell them that it was not
good idea? The user experience was not pleasant.

 

[BartC]

I do understand assembly language, but I still didn't understand the
point being made.

The listing (from Joe Keane) contains a fragment of C with an excellent
suggestion in it:

char *bar[2] =
{
"jjj",
(char []) { "kkk" },
};

The construct (char []){ "kkk" } is called a compound literal and
represents a anonymous object of the type the heads it up -- in this
example char array of char. The resulting object is writable.

The array bar contains two pointers to the start of two arrays. The one
built from a string literal is not writable, but the one built by the
compound literal is. Pretty much what you want.

The whole thing looked like gobbledygook to me. But looking at it again
after reading your post, it just seems to be a sequence of Unix-like
commands and output. It displays some C code (as above), and the ASM it
generates:

.data
__compound_literal.0:
.string "kkk"

.section .rodata
.LC0:
.string "jjj"

.data
bar:
.long .LC0
.long __compound_literal.0

The pertinent points are that "jjj" is in a read-only ("rodata") section of
memory, and "kkk" is in a normal writeable data area, if I've correctly
guessed what those directives mean. However I wouldn't know if any compiler
other than "cc" would always do the same.

 

[BartC]

On 01/21/2014 04:39 PM, Rick C. Hodgin wrote:

Try this, and then just always start at 1 instead of 0, and process until
you reach null:

const char *archiveFormats[] = {
null
#if CPIO_SUPPORTED
,"cpio"
#endif
#if TAR_SUPPORTED
,"tar"
#endif
#if ZIP_SUPPORTED
,"ZIP"
#endif
#if APK_SUPPORTED
,"apk"
#endif
,null
};

As he said: ugly. The two extra nulls (and "null" needs to be defined)
seem far worse to me than the extra comma - they survive into the object
file, and even into the final executable, taking up extra space. The
extra comma disappears during translation phase 7 and has no impact on
the actual executable.

I don't understand the need for the prepended comma and the two nulls. I
would just have everything with a trailing comma, then have NULL as the
final element, which also serves as a useful sentinel instead of trying to
figure out the length of the list.

And when I generate such list using a proper language (not macros), then the
extra logic to suppress a comma at the end is trivial.

But, perhaps commas used for list elements can just be called element
terminators rather than separators. With the final one being optional.

 

[Rick C. Hodgin]

How about this?
@ cat bar.c
char *bar[2] =
{
"jjj",
(char []) { "kkk" },
};

Schoolmaster Joe, brilliant! Fantastic! Thank you!

#define _rw(x) (char []) { x }

char* bar[] =
{
"jjj",
_rw("kkk"),
};

Works in GCC. Visual C++ is non-compliant though and doesn't support this
syntax. Still, a truly excellent solution!

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

Then there is a third group: insipid whiners about trailing commas being
allowed for convenience in a language they barely understand.

Kaz, I don't know about the history of C. Over time I've learned to use the
language and I have written a lot of code in it. I am currently working on a
large project written entirely in C. I understand most C code when I read it.
Much beyond a pointer to a pointer and my head starts to spin though.

I don't purport to be an expert in C standards. Never have been. Never will
be. I have no interest in becoming an expert in that. I came here asking for
something specific and no one had a solution for me, just workarounds. That
was, until this solution was introduced:
char* list[] = { "jjj", (char[]){"kkk"}}.

That was THE solution I was looking for. Unfortunately Visual C++ doesn't
support it, but that's a totally separate issue.

You say I do not know the language. You are correct. I asked on this group
for assistance, those who should know the language, and I received several
responses from people who "do know" the language and was told what I was
looking for didn't exist in C, only to find out later it does. I was able
to construct the exact macro I was after as well:

#define _rw(x) (char []) { x }

char* list[] = {
"one",
_rw("two")
};

And it works! Now I have what I came here for. All of my goals were met by
one individual who does know C, or at least this part of C.

For the record, none of my goals were met by any of your suggestions.
I wish you well, Kaz. I appreciate any help you've provided.

My current C project:
https://github.com/RickCHodgin/libsf

If anyone would like to help, I'm:
(1) Developing a new virtual machine
(2) Developing a new C-like language with edit-and-continue abilities
(3) Introducing several new features into the language
(4) Adding support for Visual FoxPro (a dBase derivative with very
strong databasing abilities).

My target platforms are:
(1) Windows
(2) Linux
(3) FreeBSD
(4) Android

I would welcome any developer looking to help create a free and open
alternative (what I call "liberty software") to those thing which exist
today, Java, .NET, Microsoft tools, and GNU tools. I am doing this as a
Christian with the purpose of giving away all of the products. My website
will ultimately have both a download button, and a donate button. I/we
give to them, and they, if they choose, give back to us.

I have a lot of great ideas. I would welcome assistance. I want nothing
less than to produce the best possible developer environment and toolset
that exists. If you're interested ... come on board. Email me.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

I do understand assembly language, but I still didn't understand the
point being made.

The listing (from Joe Keane) contains a fragment of C with an excellent
suggestion in it:

char *bar[2] =
{
"jjj",
(char []) { "kkk" },
};

The construct (char []){ "kkk" } is called a compound literal and
represents a anonymous object of the type the heads it up -- in this
example char array of char. The resulting object is writable.

The array bar contains two pointers to the start of two arrays. The one
built from a string literal is not writable, but the one built by the
compound literal is. Pretty much what you want.

Ben, excellent observation! And it's exactly what I wanted. Thank you for
making it clear. I have dyslexia and sometimes I have a difficult time
reading (and understanding what I'm reading). If someone can read it
to me I have much better comprehension.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

Are you acknowledging that text mode is useful?

I can see how it can be in certain cases. On the whole, no. There are
simply too many variables on input files to rely upon something that may
or may not make your task easier. It's easier and better (from a debugging
and maintenance point of view) to account for the variables yourself. If
there is a later problem you can step through your code exactly and then
know explicitly what was causing the error.

If C had defined specified sizes for predefined types, then int would
probably be 16 bits and long would be 32 (the sizes they had in early
PDP-11 implementations).

That's no problem. I have created variables in my RDC which relate to
the bit size. Had these been introduced from the beginning, they would've
been straight-forward to anyone approaching the language:

s = signed, u = unsigned, f = floating point
s8, u8
s16, u16
s32, u32
s64, u64
f32, f64

And with modern additions like the double-double and quad-double floating
point extensions using floating point hardware:
f128, f256

And with modern extensions like MPFR:
fN

And other types which can be added.

Or perhaps not. The first edition of K&R, the book that defined the
language in 1978, showed int with a size of 16 bits on the PDP-11, 36
bits on the Honeywell 6000, and 32 bits on the IBM 370 and Interdata
8/32. None of those platforms had a 64-bit integer type, because 64-bit
integer arithmitec was not supported on the hardware of the time.

Which of those choices would you want to impose on all C implementations
for all platforms?

I would NEVER have defined a type like CHAR or INT or LONG. It would ALWAYS
have been of the bit size and signedness. That way I would know exactly
what I was using no matter the platform.

On the other hand, if you want fixed-width types, you can use int8_t,
int16_t, int32_t, and int64_t, defined in <stdint.h>, which was added to
the language by the 1999 standard.

When was C created? The same should've been added far earlier as first-class
citizens of the language, native throughout.

I suggest you need to be more familiar with what's already been done.
Reinventing the wheel is fine, but you may find that someone has already
figured out how to make it round.

It's lame. Even the 1999 syntax int16_t is lame. I'm expected to type that
many characters in for every use. We are human beings. We deal with
particular things. And no matter what a compiler can understand, we read
source code. The requirement of having that kind of declaration is silly.

I even struggle with s8 being two characters, and s16 and later being three.
I have tried various alternatives to make s8 be three so they're all equal.

The purposes of RDC are an integrated system which provides much GUI support
for developers. Some things have to be clunky in source code to convey
accurately the intended meaning ... however, it doesn't have to be shown to
the developer that way. The GUI will replace a lot of clunky code requirements
with more reader-friendly forms which convey the same meaning.

The VVM I'm building, and the associated language RDC, is part of an
exceedingly flexible and expandable platform. RDC is one language, as is
VXB++ (the xbase portion). They will initially exist, but there is nothing
to prevent a fully compliant C, C++, BASIC, or any other language from also
being added and used with the same tools provided a few crucial components
are added to support it.

There are better ways to serve human beings than rigid mechanics which make
sense logically, but are completely non-intuitive for daily use.

This is all my opinion. Everyone else may disagree. But for me it's been of
such a strong driving force within me that the last 20 years of my life have
been spent in pursuit of changing it. For the record I've only made some
progress and have hit wall after wall after wall in trying to move forward,
the enemy of this world pounding on me, preventing me from proceeding because
my goals are to serve people, not money.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

This thread is, I think, the first time I've ever seen someone react
to the information that string literals aren't writeable in a way
that suggests that they think this is a bad idea.

Interesting. To recap, my reasoning relates to the nature of software and
computers in general. They are just that: computers. They take input, process
it, and generate output. That, by definition, means read-write. The only
cases where I would like to have something be read-only is when I explicitly
cast for it, indicating that this variable should not be modified. In that
way the compiler can help catch errors, as can the runtime environment.

I believe everything should be read-write unless explicitly cast otherwise.
Or, at the very least, there should be a global flag that marks everything
read-only unless explicitly cast, or everything read-write unless explicitly
cast, but it should be an all-or-nothing proposition by default.

My opinion. YOMV.

Best regards,
Rick C. Hodgin

 

[David Brown]

I cannot help but consider the fact that Google Groups provides a frew
web-based interface which removes shortcomings in the text-based Usenet
group. It allows HTML messages, longer lines with automatic wrapping,
immediate access to many groups, complex searching, and more.

Thunderbird provides most of this (though not "instant" access to other
groups), with a gui, and still manages to work perfectly well with
existing Usenet standards. (I use Thunderbird and
news.eternal-september.org myself.)

It seems that the future may be speaking, in an attempt to bring Usenet
into the 2010s and beyond.

Text-based interfaces were nice ... they used the technology available at
the time (limited disk space, limited memory, slower clock speeds). But
the technology of the 2010s is significantly beyond anything we've had
previously. Most modern multi-core CPU desktops with 8+ GB of memory,
1+ TB of disk storage, an average to high-end GPU, have more computing
power than supercomputers did 15+ years ago.

GUIs provide a far better user experience, and are only becoming more
common as time goes on. Smart phones. Tablets. Touch screen. We're
changing our computing needs.

There is a place for guis, and a place for text interfaces - I find both
essential in different situations. But there is /no/ place for an
interface that arbitrarily causes trouble for other interfaces.

 

[Rick C. Hodgin]

This sounds sort of similar to the "packer/mapper" model sometimes used
to describe the way people model things.

I've never heard of that model.

And yet, you never get around to stating what the relevance of this is. It
sort of comes across as though you intend to express that you are one of
the people who is doing the rare thing that involves a deeper desire to
understand, while the people who don't share your intuition for what string
literals should do are all presumably of the other sort...

It's not just about string literals, but it is a way of life. There area
handful of things I remain in "learn how to use mode" because I don't care
to understand the underlying philosophy. Most things in my life I am in
"pursue the philosophy" mode so I can understand it.

In my experience that is a rare trait. It took me many years to realize and
identify the differences in people. It was observation-based over a long
time. It's not an attempt to be judgmental upon myself or others, but to
recognize that some people do this, and others don't (most others).

FWIW, I feel this is happening now with people who blindly follow after new
technologies like .NET and the Apple ecosystems. These are big-business
pushes designed to control people, control access to data, have access to
data (remote server farms), to close people in, to herd them into corrals,
and so on.

What I want to do with my VVM, Visual FreePro, VXB++, RDC, and ultimateley
my own operating system, is to provide an alternative to that. I am looking
to free people from artificial ties.

Even today in Linux we have NO IDEA what is in there because there are binary
blobs being added. What backdoor viruses do these introduce? What snooping
access to code like Intel's vPro which convey out-of-band communications at
the motherboard level (CPU+motherboard+network). We don't know.

I don't want a world like that. I want a world based upon helping people,
not corporations. Upon giving and sharing, not hoarding and confining.

There are more resources in a group of people who are shown everything, where
everything is explained to all as through wide education, than there are in
a closed group of a few who have received even far greater education.

Parallel performs massively beyond serial ... and that in all things.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

There is a place for guis, and a place for text interfaces - I find both
essential in different situations. But there is /no/ place for an
interface that arbitrarily causes trouble for other interfaces.

The GUI is as far superior to text-based interfaces as anything is superior
to anything else. The time for text-base interfaces is past. It's time to
move toward the parallel nature of our growing world, and away from the
serial nature.

Everything in the future will be done in parallel. In fact, I believe our
next big breakthrough in computers will be in a massively parallel compute
engine that basically replicates all processing simultaneously in many cores,
yet with subtle differences, allowing computed work to be derived with little
or no overhead -- i.e. quantum-like computing.

Best regards,
Rick C. Hodgin

 

[Ben Bacarisse]

"Ben Bacarisse" <[email protected]> wrote in message

The listing (from Joe Keane) contains a fragment of C with an excellent
suggestion in it:

char *bar[2] =
{
"jjj",
(char []) { "kkk" },
};

The construct (char []){ "kkk" } is called a compound literal and
represents a anonymous object of the type the heads it up -- in this
example char array of char. The resulting object is writable.

The pertinent points are that "jjj" is in a read-only ("rodata")
section of memory, and "kkk" is in a normal writeable data area, if
I've correctly guessed what those directives mean. However I wouldn't
know if any compiler other than "cc" would always do the same.

It's a red herring. A conforming C compiler must implement the
semantics of the construct. How it does it is, for me, noise.

 

[Ben Bacarisse]

[...] I asked on this group
for assistance, those who should know the language, and I received several
responses from people who "do know" the language and was told what I was
looking for didn't exist in C, only to find out later it does.

That's not really what happened. You asked if there was a way to make
string literals writable and got a correct answer to that questions.
That's a problem with Usenet. Too specific a question can make people
focus on that rather than the wider issue.

The wider issue of whether you can write the sort of code you showed
without naming all the temporary character arrays happens to be yes.

I'm annoyed I didn't think of it myself, being a big fan of compound
literals, but I had already got turned off by your telling everyone how
things could be so much better without extra commas being allowed and if
the standards committee had a brain between them. I stopped thinking
about the original issue. Fortunately Joe Keane didn't.

<snip>