Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on Macro to verify that an expression has no side effects at compile time

Post

Macro to verify that an expression has no side effects at compile time

+2
−0

I'd like to implement a macro strnul():

#define strnul(s)  (s + strlen(s))

But that expands and evaluates s twice. I'd like to avoid that.

I could do (using GNU extensions)

#define strnul(s)   \
({                  \
    auto  s_ = s;   \
    s_ + strlen(s_);\
})

However, this adds some other problem: a local variable named s_. This local variable must have a name different from whatever users of this function may pass as argument, as otherwise we'd have auto s_ = s_;, which can't work.

But I have reasons to pass an argument called s_, so I'd like to find a way to entirely avoid the variable. If possible, an alternative would be to do

#define strnul(s)                         \
({                                        \
    static_assert(!has_side_effects(s));  \
    s + strlen(s);                        \
})

Is it possible to somehow do this in C? Even if the solution would require using compiler extensions, I'd be interested in finding a solution.

History

2 comment threads

Array length expressions might help soon (5 comments)
That's what functions are for (3 comments)
Array length expressions might help soon
alx‭ wrote 8 months ago

Cc: Lundin‭

The C Committee is working on a proposal that would require that array length expressions be reproducible expressions (expressions without side effects). Use of ++, --, and assignment operators would result in a constraint violation. Use of functions without [[reproducible]] would be UB, although we might make it a constraint violation too. This would provide some interesting guarantees. By declaring an unused VLA, you'd make sure that the expression has no side effects.

Lundin‭ wrote 8 months ago

alx‭ Maybe they should be working on fixing the severely under-specified function attributes before moving on to that...

C is becoming C++, where poorly-specified, half-baked features are rapidly pushed out with no concern and no looking back. Before we know it, C too will have an astronomical amount of poorly-specified behavior just like C++. Programming languages should be designed to be used, not designed to be brittle and useless.

alx‭ wrote 8 months ago

Lundin‭

(I didn't receive a notification for this comment, for some reason. If I don't reply to something of yours, feel free to ping me in an email.)

Maybe they should be working on fixing the severely under-specified function attributes before moving on to that...

I'm interested if you have any specific concerns. I agree attributes are severely under-specified in general, although I suspect you mean something specific?

C is becoming C++, where poorly-specified, half-baked features are rapidly pushed out with no concern and no looking back.

Agree. And I'm trying to fight that. It's difficult, though. The reason why I joined the committee is that too much crap had been added, and I wanted to stop that. The problem is that many WG14 members are actually C++ users and implementers, and there are very few programmers whose main language is C. That should change, and I wish more old C programmers would join.

So, would you want to join WG14?

alx‭ wrote 8 months ago

And if you don't want to join the committee, please let me know any concerns you have so that I can turn them into proposals, if you don't mind.

Lundin‭ wrote 8 months ago

alx‭ I believe function attributes need to be integrated with types closer to how qualifiers are treated, or compilers don't get a chance to do anything useful with them. https://stackoverflow.com/questions/78666782/is-there-such-a-thing-as-function-attribute-correctness