| *** Storyteller has joined #automotive | 02:17 | |
| *** Storyteller has left #automotive | 02:17 | |
| *** ToxicGumbo has quit IRC | 03:46 | |
| *** ToxicGumbo has joined #automotive | 04:21 | |
| *** jacobo has joined #automotive | 07:42 | |
| *** toscalix__ has joined #automotive | 07:42 | |
| *** CTtpollard has joined #automotive | 07:47 | |
| *** apinheiro has joined #automotive | 07:51 | |
| *** persia__ is now known as persia | 08:21 | |
| *** persia has joined #automotive | 08:21 | |
| *** wschaller has joined #automotive | 09:06 | |
| *** jacobo has quit IRC | 09:42 | |
| *** jacobo has joined #automotive | 09:42 | |
| *** wschaller has quit IRC | 10:32 | |
| *** wschaller has joined #automotive | 10:59 | |
| *** jeremiah has joined #automotive | 11:13 | |
| *** Egy has joined #automotive | 11:31 | |
| *** weston has joined #automotive | 12:07 | |
| weston | hi all | 12:07 |
|---|---|---|
| weston | any misra guys? | 12:07 |
| weston | test(__FUNCTION__); void test(const char *callerName) .. I am getting a QAC violation "Msg(4:0432) [C] Function argument is not of compatible pointer type" when I used __FUNCTION__ | 12:08 |
| *** apinheiro has quit IRC | 12:10 | |
| *** fury has joined #automotive | 12:14 | |
| * rjek idly wonders what type __FUNCTION__ is; I assume it expands to a string literal via the preprocessor | 12:16 | |
| rjek | weston: IIRC, C99 defines __func__, which is of type const char[] | 12:17 |
| rjek | char[] != char * | 12:17 |
| rjek | If you have a pedantic compiler, anyway. | 12:17 |
| weston | rjek: what is the type of __func__ ? | 12:18 |
| rjek | weston: const char[] | 12:18 |
| weston | rjek: where can I see it? | 12:18 |
| rjek | If you're using C99, I'd do void test(const char callerName[static 1]); which means you'll also get a free non-NULL check | 12:19 |
| rjek | weston: ISO C99, 6.4.2.2 | 12:20 |
| rjek | Paragraph 1. | 12:20 |
| rjek | The identifier _ _func_ _ shall be implicitly declared by the translator as if, | 12:20 |
| rjek | immediately following the opening brace of each function definition, the declaration | 12:20 |
| rjek | static const char _ _func_ _[] = "function-name"; | 12:20 |
| rjek | appeared, where function-name is the name of the lexically-enclosing function. | 12:20 |
| *** apinheiro has joined #automotive | 12:22 | |
| paulsherwood | GENIVI Tools Meeting starts here (and on genivi.webex.com) in 15 mins, maybe depleted numbers since it clashes with SAT f2f | 12:46 |
| *** jjardon has quit IRC | 12:53 | |
| *** jjardon has joined #automotive | 12:53 | |
| weston | rjek: ok thanks | 12:54 |
| rjek | weston: Did that fix it for you? | 12:55 |
| rjek | It is also conceivable that your MISRA compliance tool is just wrong. | 12:55 |
| *** philrob has joined #automotive | 13:00 | |
| paulsherwood | == GENIVI Tools Team Meeting == | 13:01 |
| paulsherwood | hi folks... any official attendees today? | 13:02 |
| CTtpollard | I'm here, not sure if I fall under the official banner | 13:02 |
| paulsherwood | it may be there are few attendees because of SAT F2F | 13:02 |
| *** klausbirken has joined #automotive | 13:03 | |
| paulsherwood | philrob and klaus discuss amm session | 13:05 |
| *** wschaller has quit IRC | 13:05 | |
| paulsherwood | the agenda for the f2f should already be available on the mobile app | 13:06 |
| paulsherwood | stephen and pavel and andreas too | 13:07 |
| *** Egy has quit IRC | 13:07 | |
| *** pavelk has joined #automotive | 13:07 | |
| *** Egy has joined #automotive | 13:08 | |
| paulsherwood | review of agenda... | 13:09 |
| paulsherwood | = Confluence = | 13:09 |
| paulsherwood | on hold | 13:09 |
| paulsherwood | = Jira vs Trello = | 13:09 |
| paulsherwood | decision last week iirc was to use the public Jira rather than Trello | 13:10 |
| paulsherwood | last weeks discussion is at https://irclogs.baserock.org/automotive/%23automotive.2015-09-07.log.html#t2015-09-07T13:00:01 | 13:11 |
| paulsherwood | = Tools Team co-ordination with BIT = | 13:13 |
| paulsherwood | tbd at F2F in AMM | 13:13 |
| paulsherwood | = Build Tools = | 13:14 |
| paulsherwood | sl started to raise code generation with BIT | 13:14 |
| paulsherwood | it appeared there was no immediate requirement | 13:15 |
| paulsherwood | SAT discussion was more about generated code itself is hosted | 13:15 |
| paulsherwood | some conversation to be had between the code generator maintainers and baseline maintainers | 13:16 |
| paulsherwood | was expecting some discussion with baseline maintainers about what they would need, how to make it happen... but this didn't progress last week | 13:18 |
| weston | rjek: I checked but not working..QAC 7.1.1 is not taking __func__ | 13:19 |
| paulsherwood | most of the bit discussion had been about kronos release, so this is still an item, just not necessarily now | 13:19 |
| paulsherwood | = UML Modeling = | 13:19 |
| weston | static const char func1[] = __func__; Msg(4:0685) [C] Initializer for any object with static storage duration must be a constant expression. | 13:20 |
| paulsherwood | pavel raises point of validating uml models to match franca | 13:21 |
| paulsherwood | = Debugging and Analysis = | 13:22 |
| paulsherwood | ps asks what tools team sohuld be thinking about here | 13:22 |
| paulsherwood | pavel mentions DLT, target monitoring etc | 13:23 |
| paulsherwood | andreas mentions EB RACE | 13:23 |
| paulsherwood | (but this is not open yet) | 13:24 |
| paulsherwood | pavel mentions a plugin for DLT daemon to capture data from target | 13:25 |
| paulsherwood | (but this may also be closed) | 13:26 |
| paulsherwood | currently our interest is mainly DLT viewer | 13:27 |
| paulsherwood | sl asks if TT should be getting involved in marketing DLT (thin end of a wedge maybe) | 13:29 |
| paulsherwood | pr had raised the suggestion of TT getting more proactive with community for commonapi | 13:30 |
| paulsherwood | (specifically, because commonapi is central to genivi) | 13:32 |
| paulsherwood | pk mentions that commonapi is key to how integration should happen | 13:33 |
| paulsherwood | let's talk more specifically on this at amm | 13:34 |
| paulsherwood | = Automated Testing = | 13:34 |
| dzen | = Automotivated Testing = | 13:35 |
| paulsherwood | ;-) | 13:35 |
| FelixH | xD | 13:37 |
| paulsherwood | ps raised that generic CIAT seems less interesting to AGL than he had thought... AGL people last week appear most aligned to the Poky approach | 13:39 |
| *** Egy has quit IRC | 13:43 | |
| * paulsherwood takes an action to summarise the CIAT discussion on the mailing list | 13:54 | |
| paulsherwood | = GENIVI AMM = | 13:54 |
| paulsherwood | there will be a session on commonapi | 13:54 |
| paulsherwood | this will be similar to the session from the spring amm | 13:54 |
| paulsherwood | there will be a tools f2f too | 13:55 |
| paulsherwood | = AOB = | 13:55 |
| paulsherwood | none | 13:56 |
| paulsherwood | == GENIVI Tools Team Meeting ends == | 13:56 |
| *** philrob has quit IRC | 13:57 | |
| rjek | weston: Can I see the relevant lines of code? | 13:57 |
| rjek | weston: And do you know which version of ISO C you are using? | 13:57 |
| *** ToxicGumbo-work has joined #automotive | 14:02 | |
| *** Egy has joined #automotive | 14:05 | |
| *** fredcadete has quit IRC | 14:09 | |
| weston | rjek: it is proprietary code. But I gave the exact replica | 14:23 |
| weston | rjek: test(__FUNCTION__); void test(const char *callerName) | 14:24 |
| weston | {} | 14:24 |
| *** klausbirken has left #automotive | 14:25 | |
| weston | rjek: ISO C99 | 14:26 |
| weston | in x86-gcc and arm-gcc | 14:27 |
| weston | but using QAC 7.1.1 | 14:27 |
| *** jlrmagnus has joined #automotive | 14:29 | |
| rjek | weston: And if you change the signature of test() to void test(const char callerName[static 1]); ? | 14:32 |
| rjek | (And use _func_ not __FUNCTION__) | 14:33 |
| rjek | err, __func__ even | 14:34 |
| rjek | ie, try compiling: void test(const char callerName[static 1]) { } int main(int argc, char *argv[]) { test(__func__); } | 14:34 |
| * CTtpollard finally has access to wayland_debug | 14:35 | |
| rjek | weston: ^ | 14:37 |
| weston | rjek: thinking | 14:37 |
| weston | rjek: didn't get the logic | 14:38 |
| weston | const char callerName[static 1] | 14:38 |
| rjek | weston: The type of __func__, which is defined by C99, is const char[] | 14:38 |
| rjek | weston: The static 1 just gives you a free compile-time non-NULL pointer check | 14:38 |
| * weston free compile-time non-NULL pointer check !! | 14:39 | |
| * weston confused | 14:39 | |
| rjek | weston: The compiler will emit an error if you call test(NULL); | 14:39 |
| weston | rjek: but here the situation is different right? | 14:41 |
| rjek | weston: I think you should ignore the static 1 and see if your MISRA tool complains if you use __func__ and const char callerName[] :) | 14:41 |
| weston | rjek: wait | 14:42 |
| weston | rjek: please hold. | 14:44 |
| * rjek holds onto himself, for the lack of anything else to do so | 14:44 | |
| * weston waiting for QAC licence | 14:45 | |
| * weston floating license | 14:46 | |
| rjek | MISRA and all its tooling, AFAICT, is designed to maximise one's miserableness. | 14:46 |
| *** pavelk has quit IRC | 14:47 | |
| weston | rjek: checked.. | 14:48 |
| weston | Msg(4:3408) 'test' has external linkage and is being defined without any previous declaration. | 14:48 |
| weston | Msg(4:1052) [C99] A variable length array of unspecified size has been declared. | 14:49 |
| rjek | weston: Your MISRA tool is broken. | 14:49 |
| weston | Err(9:0907) [S] Unexpected token. <next> | 14:49 |
| rjek | I suggest requesting a refund. | 14:49 |
| weston | Err(9:0907) [S] Unexpected token. | 14:49 |
| weston | Msg(4:0432) [C] Function argument is not of compatible pointer type. <next> | 14:49 |
| rjek | You can get rid of the first error probably by changing the defination of test to have "static" | 14:49 |
| rjek | weston: Yep, your MISRA checking tool is most certainly broken. | 14:50 |
| weston | rjek: confused | 14:50 |
| rjek | weston: The tool you are using does not understand valid C. | 14:50 |
| weston | rjek: no idea | 14:51 |
| weston | rjek: You can get rid of the first error probably by changing the defination of test to have "static" | 14:51 |
| weston | already we have static isn't it? | 14:51 |
| weston | void test(const char callerName[static 1]) { } int main() { test(__func__); } | 14:51 |
| weston | rjek: ^^ | 14:52 |
| weston | paulsherwood: hello | 14:53 |
| paulsherwood | weston: hi! | 14:53 |
| weston | paulsherwood: how are you | 14:53 |
| paulsherwood | jetlagged :) | 14:53 |
| weston | paulsherwood: any travels? | 14:53 |
| rjek | weston: static void test(const char callerName[static 1]) { } int main(int argc, char *argv[]) { test(__func__); return 0; } | 14:54 |
| rjek | weston: If your MISRA compliance tool makes any complains about that, it is broken. | 14:54 |
| weston | rjek: please wait..let me check..btw the company has paid more $$$ | 14:56 |
| weston | for this tool | 14:56 |
| rjek | (Or it only understands C89, which would be sad and mean it was not suitable for testing your C99 code.) | 14:56 |
| rjek | weston: IME, the most expensive and Enterprise™ the software, the worse it is :) | 14:56 |
| weston | rjek: I am using QAC 7.1.1 | 14:56 |
| weston | rjek: not always :) | 14:57 |
| weston | rjek: generally faces huge issues with opensource | 14:57 |
| weston | g: my laptop failed with latest update of ubuntu | 14:57 |
| rjek | weston: The snippet I gave you is totally valid C99 and the pointer types agree. If your tool cannot parse it or says the pointer types don't agree, it's broken, regardless of how much you paid for it :) | 14:59 |
| weston | rjek: Err(9:0907) [S] Unexpected token. <next> | 14:59 |
| weston | rjek: Err(9:0907) [S] Unexpected token. | 15:00 |
| weston | rjek: Msg(4:1052) [C99] A variable length array of unspecified size has been declared. | 15:00 |
| weston | rjek: Msg(4:3450) Function 'test', with internal linkage, is being defined without a previous declaration. | 15:00 |
| weston | rjek: Msg(4:0432) [C] Function argument is not of compatible pointer type. <next> | 15:01 |
| weston | rjek: may be QAC 7.1.1 wont support C99 ? | 15:01 |
| weston | rjek: in that case, how can I back port this statement to work in C90 atleast? | 15:01 |
| * rjek tries to ask for a trial copy of QAC so he can test it himself, but their website is broken :) | 15:02 | |
| weston | rjek: ohh | 15:02 |
| rjek | weston: The [C99] error suggests it pretends to understand C99 | 15:02 |
| rjek | weston: I would suggest you write code to work, rather than write code to work around bugs in a static analysis tool. | 15:03 |
| weston | rjek: http://www.programmingresearch.com/products/qac/ | 15:03 |
| rjek | weston: yes, that site. It says my email address is invalid. | 15:03 |
| rjek | These people clearly can't read specification documents :) | 15:03 |
| weston | rjek: I need to pass all QAC violations :( | 15:03 |
| weston | otherwise, I dont get my payment :( | 15:04 |
| rjek | That's a shame if the tool can't accept valid C code and erronously reports type errors. | 15:04 |
| weston | rjek: this month, I am totally out of pocket | 15:04 |
| myself | Heh. Guy here with longfirstname.longlastname@hyphenated-numb3rdomain.com breaks so many signup forms, it's not even funny. | 15:04 |
| rjek | myself: It appears QAC's website assumes the only valid characters for the local part of an email address are [a-z0-9._] | 15:04 |
| myself | I've been known to mail printed copies of the relevant RFC to a domain's technical contact. | 15:05 |
| myself | Nothing says "I think you suck" like a hand-written message in a card attached to half a pound of dead tree. | 15:06 |
| weston | rjek: oops | 15:06 |
| rjek | myself: :D | 15:07 |
| * weston almost fed down with this | 15:08 | |
| weston | I have almost 1000 places this __func__ | 15:08 |
| weston | in my 40K loc | 15:08 |
| weston | oops | 15:08 |
| rjek | weston: Send QAC an email with that code snippet and refer them to ISO/IEC 9899:201x, section 6.4.2.2, paragraph 1. | 15:09 |
| *** jlrmagnus has quit IRC | 15:10 | |
| weston | rjek: if they telll, QAC 7.1.1. wont support C99 then? | 15:11 |
| weston | rjek: I need to back port to C90 | 15:11 |
| weston | rjek: any idea? | 15:11 |
| rjek | weston: The errors you're pasting suggests it knows of C99 | 15:11 |
| rjek | Msg(4:1052) [C99] A variable length array of unspecified size has been declared. | 15:11 |
| rjek | I don't understand this error. a) there is no variable length array in that snippet, b) if you specified the size of a variable length array, it wouldn't be variable length, it would be a specific length. | 15:12 |
| weston | rjek: okay | 15:12 |
| weston | rjek: could be unspecified size has been declared. --> static 1? | 15:13 |
| rjek | No, that's explicitly specifying a minimum bound to the size | 15:14 |
| weston | rjek: it has not taken it | 15:14 |
| weston | rjek: Unexpected token. --> 1 | 15:14 |
| rjek | Further more, [] in function parameter declarations has nothing to do with variable length arrays | 15:14 |
| rjek | The unexpected token suggests it cannot parse perfectly valid C codfe | 15:15 |
| rjek | code | 15:15 |
| weston | Err(9:0907) [S] Unexpected token. <next> --> static | 15:15 |
| rjek | weston: Do you need to tell this tool that the sources are in C99 and not C90? | 15:15 |
| weston | rjek: how ? | 15:15 |
| weston | rjek: that is not clear | 15:15 |
| rjek | I have no idea, I don't have a copy :) | 15:15 |
| rjek | qac --help? :) | 15:15 |
| weston | rjek: I will check | 15:16 |
| weston | rjek: mean time, are we able to port our code to work in C90? | 15:16 |
| rjek | weston: I don't know. I don't think __FUNCTION__ is standardised, which is why C99 introduced __func__ | 15:17 |
| weston | rjek: okay | 15:18 |
| rjek | If you're only ever going to be compiling with a good modern compiler, such as GCC or clang, then you might get away with it. But not all compilers that support __FUNCTION__ even put the same thing in there | 15:18 |
| rjek | If you're compiling with some random expensive embedded toolchain, you may be out of luck | 15:18 |
| weston | rjek: I will check if I can configure QAC to use C99 | 15:18 |
| rjek | OK | 15:18 |
| rjek | Also, next time, explain that static analysis tools are a guide for development and that making zero reports being an acceptance criteria leads to more code, more bodges, and less reliability. | 15:19 |
| rjek | :) | 15:20 |
| weston | rjek: but my company strictly follows the process | 15:24 |
| weston | rjek: they work for automotive and avionics | 15:24 |
| rjek | It sounds like your company's process needs to change to be more realistic :) | 15:24 |
| weston | and strict code | 15:24 |
| weston | rjek: ASIL C | 15:24 |
| weston | and follows ISO26262 | 15:24 |
| rjek | You can have perfectly reliable C code that produces loads of erroneous linter errors, and totally unreliable C that produces none. | 15:25 |
| rjek | ergo -> making zero reports from a linter an acceptance criteria is a waste of everybody's time | 15:25 |
| JEEB | I remember we had a criteria of removing all "security" related static analysis warnings once, unless we could explain how it was a false alarm | 15:26 |
| rjek | Yes, having it be lint-clean excluding explanations of where the linter is confused or buggy is OK | 15:26 |
| rjek | In weston's situation, the linter is confused or buggy. | 15:26 |
| JEEB | yeah | 15:26 |
| rjek | And thus adding /more/ code to appease the linter is the only option, which is clearly insane. | 15:27 |
| JEEB | aye | 15:27 |
| * weston hard core google searching..sent mail to prqa | 15:31 | |
| *** jeremiah has quit IRC | 15:33 | |
| ToxicGumbo-work | Anyone know why the AGL SAT meeting minutes stop in February? No more minute taking or no meetings? | 15:48 |
| ToxicGumbo-work | https://wiki.automotivelinux.org/agl-sat-meetings | 15:48 |
| *** CTtpollard has quit IRC | 15:49 | |
| *** CTtpollard has joined #automotive | 15:49 | |
| *** CTtpollard has quit IRC | 15:57 | |
| *** CTtpollard has joined #automotive | 15:58 | |
| paulsherwood | ToxicGumbo-work: there have been more meetigns for sure, i don't know what happens wrt minutes | 16:00 |
| *** bbranch has joined #automotive | 16:11 | |
| ToxicGumbo-work | paulsherwood: Thanks | 16:15 |
| *** bbranch has left #automotive | 16:16 | |
| paulsherwood | ToxicGumbo-work: recent meetings have been documented here | 16:17 |
| paulsherwood | (imperfectly) | 16:17 |
| ToxicGumbo-work | Were videos made of last week's AGL Fall 2015 talks? | 16:30 |
| paulsherwood | ToxicGumbo-work: not as far as i could tell... no AV team | 16:31 |
| ToxicGumbo-work | Thanks | 16:31 |
| paulsherwood | ToxicGumbo-work: AlisonChaiken's talk was great - her slides are at http://she-devel.com/AGL_systemd_2015.pdf | 16:33 |
| paulsherwood | i'm hoping all attendees were properly convinced that systemd is not optional :) | 16:34 |
| ToxicGumbo-work | AlisonChaiken is the bee's knees. She's all over IRC keeping disassociated groups updated. Major commitment to the cause. | 16:36 |
| ToxicGumbo-work | That was the talk I was hoping to watch | 16:37 |
| ToxicGumbo-work | Though not exclusively | 16:37 |
| paulsherwood | my talk was more discussion than presentation... i got too far dug into AGL priorities, and realized my understanding in preparing the talk had been wrong | 16:41 |
| AlisonChaiken | Glad you found it useful, paulsherwood. It was a pleasure to have the opportunity to chat with you and Jonathan. | 16:46 |
| AlisonChaiken | I'll be giving a short course in November on systemd. | 16:46 |
| AlisonChaiken | I'm posting a longer set of slides and some containers in which to run the exercises. | 16:47 |
| AlisonChaiken | They're at http://she-devel.com/LISA15/LISA15_systemd.pdf | 16:48 |
| ToxicGumbo-work | Thanks to you both. | 16:48 |
| AlisonChaiken | Not done yet, but at TLD is the ODP. CC-by-sa, so make free with them. | 16:48 |
| paulsherwood | :) | 16:48 |
| AlisonChaiken | I wish LF would just pay free-electrons to record all the meetings. | 16:49 |
| AlisonChaiken | They do a great job. | 16:49 |
| ToxicGumbo-work | Alison, have you attended LISA much? I haven't been since the first or so. Would be funny if we met. | 16:49 |
| *** weston has quit IRC | 16:57 | |
| AlisonChaiken | ToxicGumbo-work, I've never considered attending LISA, as I'm certainly not a sysadmin. | 17:05 |
| AlisonChaiken | My history in SW engineering is only a few years at any rate, as I worked on magnetic and optical recording materials development for most of my career. | 17:06 |
| *** Egy has quit IRC | 17:11 | |
| *** toscalix__ has quit IRC | 17:12 | |
| *** toscalix__ has joined #automotive | 17:13 | |
| *** riazantsev has joined #automotive | 17:36 | |
| *** jacobo has quit IRC | 18:08 | |
| *** Egy has joined #automotive | 18:12 | |
| *** jlrmagnus has joined #automotive | 18:17 | |
| *** jlrmagnus has quit IRC | 18:23 | |
| *** apinheiro has quit IRC | 18:50 | |
| *** jlrmagnus has joined #automotive | 19:25 | |
| *** jlrmagnus has quit IRC | 19:34 | |
| *** toscalix__ has quit IRC | 19:37 | |
| *** fernandod has quit IRC | 19:46 | |
| *** jlrmagnus has joined #automotive | 19:46 | |
| *** fernandod has joined #automotive | 19:46 | |
| *** jlrmagnus has quit IRC | 20:22 | |
| *** ToxicGumbo-work has quit IRC | 21:15 | |
| *** Egy has quit IRC | 21:39 | |
| *** Egy has joined #automotive | 22:26 | |
| *** Egy has quit IRC | 22:31 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!