How can I make use of named constants in ACSL specifications? These constants are either Macros (#define MY_CONST ...) or constant declarations (const int MY_CONST ...). The former does not work since the macros are not expanded by the preprocessor (ACSL specs are C comments), the latter does not because the constants are treated as variables so that some proofs fail. The specification works fine if I replace the named constants with the actual numbers.
Does anyone have a good idea to handle named constants?
Thanks in advance
In order to expand macros in ACSL specification, you can use the -pp-annot option.
I could resolve the problem with assistance of Pascal Cuoq. It is actually not a problem with frama-c but with gcc. One needs the -fpreprocessed compiler option. My complete command is now:
frama-c -cpp-extra-args="-I `frama-c -print-share-path`/libc" -cpp-extra-args="-nostdinc" -cpp-extra-args="-fpreprocessed </path/to/stdc-predef.h>" -wp -wp-rte -pp-annot myfile.c
Related
I'm new to Ada and as far as I could explore on the internet, I was unable to find an analog to this C++ concept.
Say I have package_name.data_member (multiple variables in various packages). I'm hoping to shorten that to a more reader-friendly manner like below (without using the Use keyword) because those variables will be used multiple times in the same file -
#define A package_name.data_member
#define B package_name.data_member
...
Is there a way I can do the above in Ada?
In this case you need an object renaming declaration (ARM 8.5.1):
A : Data_Member_Type renames Package_Name.Data_Member;
If you’re using GNAT, it includes a tool gnatprep; the major differences from cpp are that
symbols to be substituted have to be marked in the source text, e.g.$foo($ isn’t in the Ada source character set),
substitutions can only be defined in a separate definitions file (or e.g -Dfoo=bar on the command line).
There is no exact analogue of #define (or any pre-processing) in standard Ada (although you could use a macro preprocessor if you need that), but for this use a renaming declaration should suit:
A : Atype renames package_name.data_memberA;
B : Btype renames package_name.data_memberB;
This has the advantage, over #define, that the tokens A and B are not mistakenly replaced by their #defines in unintended places.
I'm looking for idea on how to overwrite a function without modify the source. Like if I have foo() in the original source, I want to overwrite it with my own version with the same function name by adding it in a C file, which may also contains other overwrite functions. Sort of like strong/weak compilation. Currently I have to go in the source files and ifdef with __FRAMAC__. I don't want to touch the source files. Is there some kernel option to not use the second instance of foo() function?
Your question does not specify whether you want to replace a function declaration or a function definition. Since they are handled differently by Frama-C, I'm going to detail both.
Duplicate definitions at the kernel level
Currently, at the parsing level, there is no option in Frama-C to completely ignore the definition of a function that is present in one of the files given for parsing. The Frama-C AST will incorporate the definition of all functions it finds.
There is no exact equivalent for strong/weak symbols.
If a second definition for the same function is found, one of the following will happen:
If both definitions occur in the same compilation unit, there is an error.
If each definition happens in a different compilation unit, Frama-C will try to find a plausible solution:
If both occurrences have the same signature, Frama-C will emit a warning such as:
[kernel] b.c:2: Warning:
dropping duplicate def'n of func f at b.c:2 in favor of that at a.c:1
In this case, you just need to ensure the definition you want appears later in the list of sources to be parsed.
If the occurrences have different signatures, but one of the functions is never actually used, you may have a warning such as:
[kernel:linker:drop-conflicting-unused] Warning:
Incompatible declaration for f:
different number of arguments
First declaration was at a.c:1
Current declaration is at b.c:2
Current declaration is unused, silently removing it
However, if both occurrences are used, then you have an error:
[kernel] User Error: Incompatible declaration for f:
different type constructors: int vs. int *
First declaration was at a.c:1
Current declaration is at b.c:2
Duplicate declarations at the kernel level
Considering function declarations, Frama-C will, in accordance with the C standard, accept as many of them as are given, provided they are compatible. If they have ACSL specifications, those specifications will be merged.
Multiple incompatible declarations are handled as before, with warnings or errors depending on whether both versions are used (in which case Frama-C is unable to choose).
Plugin-specific options
Plug-ins may have specific options to override the default behavior of functions in the AST. For instance, Eva has option -eva-use-spec <fns>, which tells the analysis to ignore the definitions of functions <fns>, using only their specifications instead.
In Julia, is there a way to write a macro that branches based on the (compile-time) type of its arguments, at least for arguments whose types can be inferred at compile time? Like, in the example below, I made up a function named code_type that returns the compile-time type of x. Is there any function like that, or any way to produce this kind of behavior? (Or do macros get expanded before types are inferred, such that this kind of thing is impossible.)
macro report_int(x)
code_type(x) == Int64 ? "it's an int" : "not an int"
end
Macros cannot do this, but generated functions can.
Check out the docs here: https://docs.julialang.org/en/v1/manual/metaprogramming/#Generated-functions-1
In addition to spencerlyon2's answer, another option is to just generate explicit branches:
macro report_int(x)
:(isa(x,Int64) ? "it's an int" : "not an int")
end
If #report_int(x) is used inside a function, and the type of x can be inferred, then the JIT will be able to optimise away the dead branch (this approach is used by the #evalpoly macro in the standard library).
Assume that I have a script that can be run in either of the following ways.
./foo arg1 arg2
./foo
Is there a generally accepted way to denote that arg1 and arg2 aren't mandatory arguments when printing the correct usage of the command?
I've sometimes noticed usage printed with the arguments wrapped in brackets like in the following usage printout.
Usage: ./foo [arg1] [arg2]
Do these brackets mean that the argument is optional or is there another generally accepted way to denote that an argument is optional?
I suppose this is as much a standard as anything.
The Open Group Base Specifications Issue 7
IEEE Std 1003.1, 2013 Edition
Copyright © 2001-2013 The IEEE and The Open Group
Ch. 12 - Utility Conventions
Although it doesn't seem to mention many things I have commonly seen over the years used to denote various meanings:
square brackets [optional option]
angle brackets <required argument>
curly braces {default values}
parenthesis (miscellaneous info)
Edit: I should add, that these are just conventions. The important thing is to pick a convention which is sensible, clearly state your convention, and stick to it consistently. Be flexible and create conventions which seem to be most frequently encountered on your target platform(s). They will be the easiest for users to adapt to.
I personally have not seen a 'standard' that denotes that a switch is optional (like how there's a standard that defines how certain languages are written for example), as it really is personal choice, but according to IBM's docs and the Wiki, along with numerous shell scripts I've personally seen (and command line options from various programs), and the IEEE, the 'defacto' is to treat square bracketed ([]) parameters as optional parameters. Example from Linux:
ping (output trimmed...)
usage: ping [-c count] [-t ttl] host
where [-c count] and [-t ttl] are optional parameters but host is not (as defined in the help).
I personally follow the defacto as well by using [] to mean they are optional parameters and make sure to note that in the usage of that script/program.
I should note that a computer standard should define how something happens and its failure paths (either true fail or undefined behavior). Something along the lines of the command line interpreter _shall_ treat arguments as optional when enclosed in square brackets, and _shall_ treat X as Y when Z, etc.. Much like the ISO C standard says how a function shall be formed for it to be valid (otherwise it fails). Given that there are no command line interpreters, from ASH to ZSH and everything in between, that fail a script for treating [] as anything but optional, one could say there is not a true standard.
Yes, the square brackets indicate optional arguments in Unix man pages.
From "man man":
[-abc] any or all arguments within [ ] are optional.
I've never wondered if they're formally specified somewhere, I've always just assumed they come from conventions used in abstract algebra, in particular, in BNF grammars.
I used scanf() in my program,when I compile it I'm getting a lot of warnings regarding use of scanf as follows:
D:\myspace\projects\nnf\NNFAdaptor\NNFAdaptor\main.cpp
C4996: 'scanf': This function or variable may be unsafe. Consider using scanf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
I also tried using _CRT_SECURE_NO_WARNINGS but it is not present in my Qt (headers),it is shown as error.
Put #define _CRT_SECURE_NO_WARNINGS at the top of your main.cpp (before any #includes).
That class of warnings is mostly wrong (particularly about what to use instead) but it really is true that you should not use scanf, because:
It is very easy to write a format specification that is dangerous in the same way that gets is dangerous, i.e. it will write past the end of a buffer without noticing. It is possible to write format specifications that don't have this problem but it is much harder.
It is almost impossible to write a scanf-based input parser that can handle ill-formed input reliably.
Overflow in any numeric conversion is technically undefined behavior, which means the C library is allowed to crash your program just because someone typed too many digits. (Good C libraries will not do anything worse than produce garbage in your result variable, but that can itself be a headache.)
You should not use scanf_s instead; it attempts to paper over problem 1 but doesn't entirely succeed, and it doesn't address problems 2 and 3 at all. Since you are using Qt, I recommend:
Read entire lines into std::strings using std::getline.
Parse them with QRegExp.
Convert numeric strings to numbers with e.g. QString::toDouble.
If your input syntax is more complicated than regexes can handle, investigate QLALR.