[GCC] can't make a calculation as part of variable setup

[IanB]

hence, why don't you try to pass examinations like ACM and SIGACT in computer science (university), and then find a job in avionics, where you will be forced to master such concepts by practical contexts?

There are two ways a program can fail:

1. The program does not do what the programmer intended, due to faulty implementation and misunderstanding about how the programming system works;
2. The program does exactly what the programmer intended, but the programmer's intentions were wrong.

I see a lot of bugs of the second kind in my daily work. Does ADA have any tools to help prevent such bugs?

[glarsson]

No. Ada doesn't even solve #1.

[Mechatrommer]

reaching page 4 for what obviously #define is a solution... and i'm sorry for the OP reluctant to it...

[mikeselectricstuff]

sounds like constants in C are still bollocks and the only true constant is a define.

So I need to split the operations up.

Sounds like you simply don't have a very good grasp of C yet.  If you define a 'const' value (const int my_const=5;), that value will exist in a memory location after the compiler has place it in the relevant memory section and the linker has allocated it an address.

So in the OP's scenario, unless the compiler is fairly smart, it would  waste memory on the intermediate constants.
#define would achieve exactly what was required on any compiler, however smart or dumb, and be understandable by any programmer, however smart or dumb.
Seems to me like the optimum solution for the OP's situation.

[mikeselectricstuff]

hence it's bad for debugging.

It's a constant. You know what its value is, so doesn't affect debugging.

[rstofer]

Just because a literal is #defined doesn't mean that it won't be allocated storage.  The ARM does not have the ability to do a MOV of a literal to a register for certain values.  You simply can't stuff a 32 bit value into a 32 bit instruction.  This will be noticeable if the literal is -1 or 0xffffffff.

I haven't checked to see how this is resolved.  The issue is discussed here:
http://www.keil.com/support/man/docs/armasm/armasm_dom1359731145835.htm

I would expect the compiler to use an LDR to grab the value out of a literal pool.  Since the value exists in the pool, it is theoretically possible to change it with a pointer to the address.  Getting the address should be difficult, I hope!

As to whether #define is evil incarnate, why not look at some production code and see if is used.  Maybe the Linux kernel.  Whatever those guys are doing is probably as close to 'normal' practices as it gets.

Here's some kernel code from an ATA driver (because that is the first file I opened):

Code: [Select]

/*
 * DaVinci DA850 AHCI SATA platform driver
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2, or (at your option)
 * any later version.
 */

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pm.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/libata.h>
#include <linux/ahci_platform.h>
#include "ahci.h"

#define DRV_NAME "ahci_da850"
#define HARDRESET_RETRIES 5

/* SATA PHY Control Register offset from AHCI base */
#define SATA_P0PHYCR_REG 0x178

#define SATA_PHY_MPY(x) ((x) << 0)
#define SATA_PHY_LOS(x) ((x) << 6)
#define SATA_PHY_RXCDR(x) ((x) << 10)
#define SATA_PHY_RXEQ(x) ((x) << 13)
#define SATA_PHY_TXSWING(x) ((x) << 19)
#define SATA_PHY_ENPLL(x) ((x) << 31)
...

No big surprise...  I would expect to see this type of thing in just about every file.

Notice the parenthesis around x in the definition.  This is critical!

[mikeselectricstuff]

It's a constant. You know what its value is, so doesn't affect debugging.

you might don't know what the value is, in fact, there are a lot of ambiguities. #define doesn't consider the type, it's just a piece of text replaced by the pre-processor with the hope the compiler will adjust (and you end forcing casting?), thus the compiler might receive an incorrect value, and the hw-debugger has neither idea nor a clue about it, especially if it's evaluated by an expression of nexted #define's

file1.h #define a=...
file2.h #define b=a+...
file3.h #define c=b+a+...
file4.h #define d=c+b+a+...
file5.h #define e=d+c+b+a+...

one or more of them is wrong, which one? do you need printf to check? can you use printf/puts? the hw-debugger can't, of course, inspect #define, you only know what is the value of "e" if you assign it to a variable.

open some project like OpenBoot for routers like TL-703, and see how many nexted #define's  are used to define what? what is the final value if you have to look at ten header files with multiple lines activated by #if #else ?

The microchip MPLABX editor auto-colours #if blocks, which makes that kind of thing a lot easier 

it's, as usual, a mess! In fact, it took 2 months to fix a wrong #define activated by a wrong #ifdef, activated by a wrong #define with some crap and candies in the middle; in the meanwhile, a bug was happy to run on my router causing a random freeze of the NIC at the bootstrap

Like I said, more or less appropriate for a given situation... ISTR the OP is talking about a small MCU system,  not a hugely complex piece of code like a router.
At the end of the day you need to get the job done. Bonus points for readability and maintainability. More bonus points for not unnecessarily relying on clever features of particular compilers.
The OP was more concerned about listening to "best practice" from "experts" than thinking about what was appropriate for his situation. That is the lesson to be learnt here.

[rstofer]

talking about a small MCU system,  not a hugely complex piece of code like a router

It's was the bootloader of the router. The complexity of a bootloader is exactly the same as the code in a small MCU system, and *the* point is focused on the abuse of the #define.

That sounds a lot like blaming the saw for the woodworker's mistake.

[Mechatrommer]

open some project like OpenBoot for routers like TL-703, and see how many nexted #define's  are used to define what? what is the final value if you have to look at ten header files with multiple lines activated by #if #else ?

probably you are talking about #defines that are used for portability (does Ada have this feature in mind?) reason, that the same code be used in different router brand that doesnt have this and this functionality. not the #define the OP is talking about here... anyway... the code (or the original programmer) is twice the clever as you are... not me saying that...

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

[mikerj]

Just because a literal is #defined doesn't mean that it won't be allocated storage.  The ARM does not have the ability to do a MOV of a literal to a register for certain values.  You simply can't stuff a 32 bit value into a 32 bit instruction.  This will be noticeable if the literal is -1 or 0xffffffff.

True, but this is architecture and value size specific.  If you are using literals, you can't assume that it can be treated like a const.  Even if possible, attempting to do so would be horrible.

It's a constant. You know what its value is, so doesn't affect debugging.

you might don't know what the value is, in fact, there are a lot of ambiguities. #define doesn't consider the type, it's just a piece of text replaced by the pre-processor with the hope the compiler will adjust (and you end forcing casting?), thus the compiler might receive an incorrect value, and the hw-debugger has neither idea nor a clue about it, especially if it's evaluated by an expression of nexted #define's

file1.h #define a=...
file2.h #define b=a+...
file3.h #define c=b+a+...
file4.h #define d=c+b+a+...
file5.h #define e=d+c+b+a+...

one or more of them is wrong, which one? do you need printf to check? can you use printf/puts? the hw-debugger can't, of course, inspect #define, you only know what is the value of "e" if you assign it to a variable.

This is when you would configure the compiler to save the preprocessed output when debugging.

[donotdespisethesnake]

tldr;

C is a terrible programming language
Few people really understand it

[Mechatrommer]

tldr;

only few people read the topic and OP and then chime in relevantly...

[rstofer]

Just because a literal is #defined doesn't mean that it won't be allocated storage.  The ARM does not have the ability to do a MOV of a literal to a register for certain values.  You simply can't stuff a 32 bit value into a 32 bit instruction.  This will be noticeable if the literal is -1 or 0xffffffff.

True, but this is architecture and value size specific.  If you are using literals, you can't assume that it can be treated like a const.  Even if possible, attempting to do so would be horrible.

It's a constant. You know what its value is, so doesn't affect debugging.

you might don't know what the value is, in fact, there are a lot of ambiguities. #define doesn't consider the type, it's just a piece of text replaced by the pre-processor with the hope the compiler will adjust (and you end forcing casting?), thus the compiler might receive an incorrect value, and the hw-debugger has neither idea nor a clue about it, especially if it's evaluated by an expression of nexted #define's

file1.h #define a=...
file2.h #define b=a+...
file3.h #define c=b+a+...
file4.h #define d=c+b+a+...
file5.h #define e=d+c+b+a+...

one or more of them is wrong, which one? do you need printf to check? can you use printf/puts? the hw-debugger can't, of course, inspect #define, you only know what is the value of "e" if you assign it to a variable.

This is when you would configure the compiler to save the preprocessed output when debugging.

Or you wouldn't write that kind of stuff in the first place.  My C compiler won't accept the '=' sign in the #define statements and I have no idea what the ellipsis expand to.

It is possible to write poor code in any language.  It isn't the fault of the language!

There's a huge difference between using #define to do some bit of literal generation and trying to get it to expand multiple files into "War and Peace".

[legacy]

yeah, whatever, I have just found another *funny* abuse of macro in a chunk of abnormal working code

this line:

Code: [Select]

#define DIV(a,b) a / b

WTF is the reason to #define it? and, worse still, why not in a safer way?

Code: [Select]

#define DIV(a,b) (a) / (b) /* safer version, well ... at least it does what is supposed to do */

2411 lines below, there is this pretty chunk of code:

Code: [Select]

   delta = DIV(x2,x1+2);

and it's of course wrong: with x2=25, and x1=3, it gives the wrong result of 10, and not 5

why? because the preprocessor expands it this way: (25 / 3) + 2 

25/(3+2) != (25/3)+2, and the following if { .. } else { .. } is completely fucked up, hence under certain conditions this is the reason for the abnormal working of the firmware I was asked to fix up.

Macros can't be debugged. When you have a macro that translates to a number or a string, the source code will have the macro name, and you can't "see" what the macro translates to. So you don't actually know what is going on. You need disassembly, and/or look at the hw-debugger.

Thus, it hasn't been immediate to realize that macro can confuse people debugging the code, and yet again, I have just messed up three hours of my time for debugging

[Mechatrommer]

Code: [Select]

#define DIV(a,b) a / b
WTF is the reason to #define it? and, worse still, why not in a safer way?

Code: [Select]

#define DIV(a,b) (a) / (b) /* safer version, well ... at least it does what is supposed to do */


(exam) question.... whose fault?
(a) the define
(b) the programmer
the answer is.... let me guess... a person with ACM exam passed and designed a hybrid language will answer.... (a) 

[Nusa]

// Finish the job of making it safer if you're going to do it at all
// You need to isolate the entire result as well as the input parameters in the macro.

// this would break your "safer" version. Modulo is same precedence as multiplication and division
delta = 100 % DIV(25,3);

[Mechatrommer]

Then definetely (a)

[mikerj]

Or you wouldn't write that kind of stuff in the first place.  My C compiler won't accept the '=' sign in the #define statements and I have no idea what the ellipsis expand to.

The example is nowhere near syntactically correct, but the gist of if should be clear.  The ellipsis simply means that more code could follow.

It is possible to write poor code in any language.  It isn't the fault of the language!

There's a huge difference between using #define to do some bit of literal generation and trying to get it to expand multiple files into "War and Peace".

You are preaching to the converted, deeply nested #defines can be a nightmare to understand/debug for someone else looking at the code.

[tggzzz]

Ever get the feeling that modern[1] C is part of the problem rather than part of the solution?

[1] C was good technology when I first used it in 1981

[Ian.M]

OTOH the ISO C++ standard committee didn't realise that C++ templates were actually a Turing complete language that  executes at compile time.  IMHO that's *WORSE* than the ANSI C preprocessor mess, with greater potential for inadvertent or deliberate obfuscation.

[tggzzz]

OTOH the ISO C++ standard committee didn't realise that C++ templates were actually a Turing complete language that  executes at compile time.  IMHO that's *WORSE* than the ANSI C preprocessor mess, with greater potential for inadvertent or deliberate obfuscation.

Hey! That's my line! Glad to see someone is listening

That debacle indicates the language was out of the comprehension of the language designers, and it hasn't got better since! If mere users produce something that "works", then it is mere good fortune

(We'll skate over the "difficulties" that debuggers have when there are templates and exceptions )

[NorthGuy]

If you take a power nailer, you can drive a nail into your foot and injury yourself. Or you can drive it into your eye and kill yourself. Does it make the power nailer less useful? or less safe? Of course not. You just don't drive nails into your body, and that's what keeps you safe.

The same thing with computer languages (also macros, and everything else). Even if you can do stupid things, you don't have to. Computer languages are tools, just as the power nailer.

[tggzzz]

If you take a power nailer, you can drive a nail into your foot and injury yourself. Or you can drive it into your eye and kill yourself. Does it make the power nailer less useful? or less safe? Of course not. You just don't drive nails into your body, and that's what keeps you safe.

The same thing with computer languages (also macros, and everything else). Even if you can do stupid things, you don't have to. Computer languages are tools, just as the power nailer.

Whoosh!

That's the sound of the key point whizzing past you, as you trot out a trite and unhelpful sound-bite.

(Unless, of course, you want to argue that it is only to be expected that the designers of power nailers refused to acknowlege that it could be used to nail yourself - until after someone demonstrated that you could nail a person. Because the C++ template designers did refuse to acknowledge their creation was Turing complete until someone rubbed their faces in it)

[legacy]

the above piece of code is the firmware of a laser-engraver, and it comes from a group of hipsters of the opensource, even if their products are closed-software.

a person with ACM exam passed

They have a cool and modern company building, with a tree-lined avenue at the entrance of the company, Mercedes business cars in front of a serious pop-art logo, and a couple of sexy girls at the reception, but I frankly doubt their "developers" have ever passed an ACM exam, since in order to pass the examination you have to understand and master the reason why abusing #define is bad.

aka, if the examinator asks you to write a piece of code for the laboratory, and you write #define div(a,b) ... well, It's for sure the best way to relist your tired ass on the examination-chair six months later 


anyway, their firmware also had other defects, got all fixed, got all the money, I can finally get my vacation

[Mechatrommer]

well if its that easy.. in fact i never have a need for #define div(a,b)... and i built few programs in VB which has no define feature let alone pointer, somewhat crippled but safer (i guess).... pascal/delphi too which i ditched long time ago. i think i can make the examiner happy otoh one thing for sure, i never come across a programming language or anybody claim that we can program at moderate complexity and it will run nicely at the first compile. if Ada is so good its should already be applauded by many serious developers around the globe and the epidemic should have infected us the "clueless" hobbiests here. isnt advancement in science should be had for free to public? why keep to Avionics?