Skip to content

Conversation

@amnuts
Copy link
Owner

@amnuts amnuts commented Nov 12, 2024

I mean... it seems to work with my very short amount of "hey, I can log in and still see the text output" testing.

Anyone fancy trying it out?

@Uzume
Copy link

Uzume commented Nov 13, 2024

Telnet, in particular telnet option negotiation, is hard to get right. I keep meaning to get back to talkers and perhaps work on a node.js/deno style talker using wasm (in C or Rust, etc.). Of course it would be easy to run it in a browser too then.

@amnuts amnuts merged commit ce6a75c into develop Nov 23, 2024
@amnuts amnuts deleted the libtelnet branch November 23, 2024 16:30
@Uzume
Copy link

Uzume commented Nov 23, 2024

I would be wary of putting path specifiers in #include as it means you cannot later move things without touching lots of code. Wouldn't be better to just add a -I to the preprocessor compiler options? There is also virtually no reason to put ./ and/or ../ in the path as #include "" should always search the current working directory (whereas #include <> usually will not) and why use ../ when you can just refer to such things in a top-down manner?

I would add paths to #include only when you want to organize your headers with some structure as a unit (meaning you want structure within a specific group of headers). If there are a number of separate software components that can be used independently and/or are from different sources just add more -I options. Only use hard-coded paths for fixed organization within a specific component. Usually that is rare and why I always stand up and take notice when such things are introduced.

Using ./ and ../ will virtually always come back to bite you and using paths in general often does too (unless there is a cohesive group of includes that have such structure within them).

An example of where adding paths might make sense would be if you wanted to organized things in src/includes. The build process could add a single -I${LOCALPATH}/src/includes and the code could then #include "folder/header.h" As it is, I think anything like that would be unnecessary as it is not that complex (we could consider breaking prototypes.h into a bunch of separate headers and organizing them the same as the .c files with command headers in a commands folder).

@amnuts
Copy link
Owner Author

amnuts commented Nov 23, 2024

@Uzume, that's some really great feedback, thanks! I changed it because I was playing around a little with https://github.com/NASA-SW-VnV/ikos for a couple minutes, and it complained about implicit includes. But I didn't really think much else through more than that, and my C and compiling knowledge is practically non-existent these days (arguably, it always was 😁). So I really appreciate your feedback, and the explanation was great. I've revert the updates in a800df6

@Uzume
Copy link

Uzume commented Nov 24, 2024

I am glad you listened.

A static analyzer like IKOS will of course complain if it cannot find all of the code so one has to make sure to provide it much of the same information that is given to the compiler (or the preprocessor in this case). It is sometimes worthwhile to attempt to analyze parts of a program and ignore such issues but they are right to complain (and a user of such a tool is right to ignore such provided they understand the limitations they are working under). Most compilers also have many static analysis options to control their warnings for the very same reasons.

Anyway, I imagine if you provide IKOS with the same -I information it will likely stop complaining about those.

Also, BTW, congratulations on v2.4.0!!! It only took more than a decade for this release. It seems you are diving back in.

I am curious what you are currently building with. Are you using gcc on Linux or something else? IKOS seems to be based around LLVM so likely it has some in common with clang and emscripten (but many things like rustc also use LLVM).

@amnuts
Copy link
Owner Author

amnuts commented Nov 24, 2024

Also, BTW, congratulations on v2.4.0!!! It only took more than a decade for this release. It seems you are diving back in.

Hah, yeah.. I really should have tagged it ages back. But I figured there was a lot in develop at the moment, and felt I should tag up before that got into main.

I am curious what you are currently building with. Are you using gcc on Linux or something else

Just gcc - basically whatever you see in the docker container and the Makefile, that's what I was using. I didn't really look too hard at IKOS; I saw it mentioned, it had a docker container to run it with, and thought I'd give it a quick spin to see what it did as-is. I really didn't go much deeper than that, tbh.

@Uzume
Copy link

Uzume commented Nov 24, 2024

I just wonder how long until we have AI-based static analysis. Of course one would have to have a large code base to train such an AI on but some groups maintain such (e.g., Black Duck; you have probably head of Open Hub formerly Ohloh; also obviously Microsoft owns GitHub so they could do something with direct access to all the code here, etc.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants