Question about C language.

[Holger]

These modern days with modern C++ it would be something modern like:

std::increment<std::atomic_lock<[](){++}>>(C);

You should consider a position in Marketing.

 

[Phishfry]

I took a side turn at Unix Programming Environment. It is quite old but it is very usable. Almost fun so far.

The Unix Programming Environment (Prentice-Hall Software Series): Brian W. Kernighan, Rob Pike: 9780139376818: Amazon.com: Books

The Unix Programming Environment (Prentice-Hall Software Series) [Brian W. Kernighan, Rob Pike] on Amazon.com. *FREE* shipping on qualifying offers. The Unix Programming Environment (Prentice-Hall Software Series)

www.amazon.com

Amazing how most every command works with examples. A few flags are different here and there.

So the shell this Unix book uses is close to the t/csh shell we use as default or rooted in the same tradition?

Can you imagine today using troff to write a book?

troff - Wikipedia

en.wikipedia.org

 

[bakul]

So the shell this Unix book uses is close to the t/csh shell we use as default or rooted in the same tradition?

Likely the original shell written by Steve Bourne.

Can you imagine today using troff to write a book?

Publications that use troff

 

[Phishfry]

Stupid off topic, but when I look at new man pages in Phab they are weirdly formated.
Is that code raw troff output?

 

[gpw928]

Can you imagine today using troff to write a book?

Clearly Donald Knuth could not, but I would say it depends on the book. I still use it, quite regularly...

 

[bakul]

Stupid off topic, but when I look at new man pages in Phab they are weirdly formated.
Is that code troff?

Either man(7) or mdoc(7).

 

[Phishfry]

Looking closer at versioning I see that there was also C-2018 and C-2024 pending.
Can I expect my ancient 'C' books to still work the same?
(Try compiling with different standards)

Which C-Standard is FreeBSD built on?

gcc has this to say: ‘ISO C99. This standard is substantially completely supported’

Different C Standards: The Story of C - open source for you

This article covers the various standards of the C language, from K&R C through ANSI C, C99, C11 and Embedded C in detail.

www.opensourceforu.com

 

[kent_dorfman766]

Either man(7) or mdoc(7).

either is preferable to that stupid gnu "info" command. Bleck!

 

[bakul]

Can I expect my ancient 'C' books to still work the same?

Stick to c89 or c99 and you will be fine. I believe K&R style declarations are going away in c23.

 

[Phishfry]

So 'Embedded C' is code written for a specific SOC like Nucleo?

Bare Metal C

Teaches you how to program embedded devices with the C programming language.

nostarch.com

Compiled with this port?
gcc-arm-embedded

 

[Phishfry]

The same if he intends to write a hardware driver.

GPIO drivers are defiantly on the list.
I have 4 in mind we need to support many more x86 GPIO platforms.

Finntek
SMSC
Nuvoton {Fix nctgpio to support more than APU2/3/4}
More in my notes....Dream Sheet more like it.

 

[drhowarddrfine]

The problem with trying to define what class C is makes you put it into a box which leads to restrictions on what it can do. I don't care for these attempts at restricting C. It's a high level assembly language that can do anything any other language can do, directly or indirectly.

 

[zirias@]

The problem with trying to define what class C is makes you put it into a box which leads to restrictions on what it can do.

I don't think so. In fact, C is an almost perfect counter-example: You can do OOP in it (and as long as you don't need polymorphism / virtual methods, it can be done in a straight forward very simple way), still it is not object-oriented.

These classifications just tell which programming paradigms are directly built into the language's constructs.

They're less useful nowadays though, as newer languages often aim to support all major paradigms. Even C++ added some "functional" constructs

 

[kent_dorfman766]

to expand on zirias@ comment, unfortunately too many newer languages and tools are solutions in search of a problem, designed by kids looking to make their mark in the world. They often don't fulfill a need, but are new and kool.

 

[Crivens]

to expand on zirias@ comment, unfortunately too many newer languages and tools are solutions in search of a problem, designed by kids looking to make their mark in the world. They often don't fulfill a need, but are new and kool.

And sometimes we get to see theflame wars of "my square wheel is cooler than your square wheel" (some people seem to be mentally stuck in the age where they put all in a square hole). If a language is domain specific, by all means make a new one if you have benefits to your cause. But don't try to force everybody into the same square hole.

 

[Paul Floyd]

This is Off-topic in a Off-topic; But
Any ideas on C23?
I personally really like the 0b literals borrowed from the embedded space .

Quite a lot of nice things

1. static_assert like C++
2. strdup finally part of the C standard
3. realloc of size 0 is UB
4. #elifdef and #elifndef
5. #embed
6. no more k&r declarations

I'm sure I've missed some big things, and there are many more small changes.

 

[yuripv79]

static_assert like C++

Reading static_assert(3):

The static_assert() macro conforms to ISO/IEC 9899:2011 (“ISO C11”).

Are they reinventing their own standards? (I have also noticed memset_explicit(), reinventing memset_s()?)

 

[Crivens]

Maybe they can come up with some construct that forbids clever optimizations without doing pragmas or asm() tricks?
doing a memset() to overwrite some values can get optimized out when you no longer can access the data by the standard. This does not prevent the data (you wish to trash) to appear in a core dump. Something like your ssh keys, for example...
edit: Ah, memset_explicit is it. But how to make this for other things?

 

[Paul Floyd]

Reading static_assert(3):

The static_assert() macro conforms to ISO/IEC 9899:2011 (“ISO C11”).

Are they reinventing their own standards? (I have also noticed memset_explicit(), reinventing memset_s()?)

It's the overload without message that is new

https://open-std.org/JTC1/SC22/WG14/www/docs/n2265.pdf

According to

`memset_explicit`

Sensitive data, like passwords or keying data, should be cleared from memory as soon as they are not needed. This requires ensuring the compiler will not optimize the memory overwrite away. This proposal adds a `memset_explicit` function that allows users to express that a memory area needs to...

www.open-std.org

memset_s() is optional. I don't know why they added memset_explicit() rather than just making memset_s() mandatory.

 

[zirias@]

strdup finally part of the C standard

I always hated the name of this function (not what it does, that's pretty convenient and often needed), because it's really a bad fit among all the other string.h functions named str*. None of them would ever allocate memory. A missed chance to find a better name for it

 

[Crivens]

I always hated the name of this function (not what it does, that's pretty convenient and often needed), because it's really a bad fit among all the other string.h functions named str*. None of them would ever allocate memory. A missed chance to find a better name for it

I think that was partly down to the name length in object files being limited to 8(?). There was one character before the name in the assembler that denoted C functions (_) and so 7 letters were left. By making function names 6 letters long they were sure no stupid linker would confuse "strdupl" with "strduplicate".

 

[baaz]

Quite a lot of nice things

1. static_assert like C++
2. strdup finally part of the C standard
3. realloc of size 0 is UB
4. #elifdef and #elifndef
5. #embed
6. no more k&r declarations

I'm sure I've missed some big things, and there are many more small changes.

I would have liked the memmem() function to be added to the standard too.

Its really handy for non null terminated strings , portions of a string and binary data.

 

[yuripv79]

I would have liked the memmem() function to be added to the standard too.

Based on notes in man page, it's so widely available that it's better than some standard (which almost no one implements fully/correctly).

 

[Paul Floyd]

Based on notes in man page, it's so widely available that it's better than some standard (which almost no one implements fully/correctly).

Hmm. Personally I prefer to have standards, which means at least there is something for everyone to aim for.

I was recently doing work on Valgrind to a) add checks for errors in sized / aligned allocators / deallocators and b) to get Valgrind to behave as closely as possible to the underlying OS / libc. I ended up writing an article about the analyis of the behaviour. https://accu.org/journals/overload/31/174/floyd/

My conclusion was that posix_memalign is pretty safe to use in a portable way (POSIX does have a small amount of wiggle room, and Solaris does behave differently in this respect to other platforms). Obviously posix_memalign isn't available on Windows.

memalign is widely available, but varies in just about every possible way between different platforms (Linux glibc being the worst, where there is simply no correlation between what the manpage claims and what glibc memalign does).

Then there is aligned_alloc. Part of the C Standard, so there seems to be some hope of portability even to Windows. But the ISO C committee bottled it and most things are "implementation defined", so not much better than memalign. And Windows (at least MS Visual C++ which probably covers 90% or more of Windows development) doesn't have aligned_alloc, but it has a _aligned_malloc.

 

[kpedersen]

Looking closer at versioning I see that there was also C-2018 and C-2024 pending.
Can I expect my ancient 'C' books to still work the same?
(Try compiling with different standards)

One advice I can give is don't get hung up on versioning with C. The reason why people do with C++ in particular is because they have a particularly organized approach from overly large language committees. And strangely I feel this bubbles back down to standard C.

For example in Java, Python, .NET (i.e VB), no-one really cares. Many still use Java 8 which is almost a decade old. Python 3.0.1 -> Python 3.2.2 is a *much* bigger jump than C++11 -> C++14 and you simply don't hear about "Modern" python books replacing older 3.x python books. Being a Rust early adopter tends to correlate with previously being an "Ultra modern C++" numpty and yet no-one really even knows what version of Rust they are using. Only C++ (and to a lesser extent C) seems to attract the version chasers / treadmillers.

Plus, POSIX currently dictates C99 so really you should be using that to adhere to POSIX which in my opinion is the most important.