C Admitting my AI usage

Yeah, i wanna see example : )
You don't need to be targeting older operating systems to encounter quite large differences. You only need to look as far as the c lib.

For example: your program accepts flags (NOTE: typed without access to compiler). real world hint: your compiler accepts arguments in any order.

C:
#include <unistd.h>
#include <stdio.h>

/**
 * This code should act as demo'd below because BSD getopt(3) acts as:
 *  "
 *    When all options have been processed (i.e., up to the first
 *    non-option argument), getopt() returns -1.
 *  "
 * EXAMPLE RUN:
 *      [test]cc -o test_getopt test_getopt.c
 *      [test]./test_getopt -n -f file.in -d default.in key=value
 *       file_string: file.in
 *       default_string: default.in
 *       arg_string: key=value
 *       show_key: 1
 *      [test]./test_getopt key=value -n -f file.in -d default.in
 *       file_string: (null)
 *       default_string: (null)
 *       arg_string: key=value
 *       show_key: 0
 *      [test]
 */
int main(int argc, char *argv[]) {
  char *file_string = NULL;
  char *default_string = NULL;
  char *arg_string = NULL;
  int keyvalue_output = 0;

  int opt;
  while ((opt = getopt(argc, argv, "f:d:n")) != -1) {
    switch (opt) {
      case 'f': file_string    = optarg; break;
      case 'd': default_string = optarg; break;
      case 'n': keyvalue_output = 1;     break;
      default:
                fprintf(stderr, "Usage: %s -f <configuration file> [-d <defaults file>] [-n] [key[=value]]\n", argv[0]);
    }
  }

  if (optind < argc) arg_string = argv[optind];

  printf(" file_string: %s\n default_string: %s\n arg_string: %s\n show_key: %d\n",
      file_string,
      default_string,
      arg_string,
      keyvalue_output);
}

So, this means that your program will act different based on the compiler that you use (gcc/cc). To fix this I (personally) use a loop and a few if's. I doubt ai would do the same (just because a built-in option like getopt(3) exists).

EDIT:
1) Fixed code: `
file_string = default_string = arg_string = NULL;`
2) var init.
 
You don't need to be targeting older operating systems to encounter quite large differences. You only need to look as far as the c lib.

For example: your program accepts flags (NOTE: typed without access to compiler). real world hint: your compiler accepts arguments in any order.

C:
#include <unistd.h>
#include <stdio.h>

/**
 * This code should act as demo'd below because BSD getopt(3) acts as:
 *  "
 *    When all options have been processed (i.e., up to the first
 *    non-option argument), getopt() returns -1.
 *  "
 * EXAMPLE RUN:
 *      [test]cc -o test_getopt test_getopt.c
 *      [test]./test_getopt -n -f file.in -d default.in key=value
 *       file_string: file.in
 *       default_string: default.in
 *       arg_string: key=value
 *       show_key: 1
 *      [test]./test_getopt key=value -n -f file.in -d default.in
 *       file_string: (null)
 *       default_string: (null)
 *       arg_string: key=value
 *       show_key: 0
 *      [test]
 */
int main(int argc, char *argv[]) {
  char file_string, default_string, arg_string;
  int keyvalue_output;
 
  file_string = default_string = arg_string = NULL;
  keyvalue_output = 0;

  int opt;
  while ((opt = getopt(argc, argv, "f:d:n")) != -1) {
    switch (opt) {
      case 'f': file_string    = optarg; break;
      case 'd': default_string = optarg; break;
      case 'n': keyvalue_output = 1;     break;
      default:
                fprintf(stderr, "Usage: %s -f <configuration file> [-d <defaults file>] [-n] [key[=value]]\n", argv[0]);
    }
  }

  if (optind < argc) arg_string = argv[optind];

  printf(" file_string: %s\n default_string: %s\n arg_string: %s\n show_key: %d\n",
      file_string,
      default_string,
      arg_string,
      keyvalue_output);
}

So, this means that your program will act different based on the compiler that you use (gcc/cc). To fix this I (personally) use a loop and a few if's. I doubt ai would do the same (just because a built-in option like getopt(3) exists).

EDIT: Fixed code: `
file_string = default_string = arg_string = NULL;`
Not to be buzz killer or anything but your code gets me SIGSEGV because there no asterisk in char, so it one byte, but my CPU is X86_64 and Kernel is 64-bits, the CPU forced the 8-byte to be 1-byte, when i reach to "printf(" file_string: %s\n default_string: %s\n arg_string: %s\n show_key: %d\n"," that "%s" is for asking RAM, and since that truncated 1-byte address points straight into forbidden Kernel territory, the CPU caught the Ring 3 violation, threw a SIGSEGV, and killed the process to protect the system.
But hey, you wrote a code bro, that some good faith in you : )
Thank you!!

Image.png
 
when i reach to "printf(" file_string: %s\n default_string: %s\n arg_string: %s\n show_key: %d\n"," that "%s" is for asking RAM, and since that truncated 1-byte address points straight into forbidden Kernel territory, the CPU caught the Ring 3 violation, threw a SIGSEGV, and killed the process to protect the system.
But hey, you wrote a code bro, that some good faith in you : )
Thank you!!

Wait, i didn't saw that, sorry!
I'm sorry I don't know what you mean by 'i wrote a code bro...'. Is that just pointing out I made a few mistakes in my code? ...I did say that I typed that without access to a compiler (that's why I included my expected output). But, I thought I did pretty good, however I replaced the variable init section so hopefully it will compile now (but the point is about getopt(3) being different in glibc and libc.
 
I'm sorry I don't know what you mean by 'i wrote a code bro...'. Is that just pointing out I made a few mistakes in my code? ...I did say that I typed that without access to a compiler (that's why I included my expected output). But, I thought I did pretty good, however I replaced the variable init section so hopefully it will compile now (but the point is about getopt(3) being different in glibc and libc.
Grammar moment.
but what i do mean is that you actually took your sweet time to do code and send to me, usually people dont do that, and that is good faith in you!
and the bug is actually because of one character, *, when you use that, it tells your compiler that the char is 8-byte and not just 1-byte, that why it causes SIGSEGV
i forgive you.
 
So, like, i have idea but instead of already making entire program, i make micro-programs to learn?
Kind of like FreeBSD/Unix.
One of the best programmers I knew told me everything he wrote was never longer than one screenfull of code. It had one job to do and it did it well.
Now, you're still learning but your code should probably start out doing one job. Get it to work. Refine it later if necessary.
 
I know, i dont trust AI 100%
I don't trust anything 100%, except for my dog. I trust myself maybe 75% but only if I have video.

AI as a tool, I think can be useful. But like all tools, "trust but verify".
AI and code: there have been tools to generate code/code skeletons for a long time. Anyone else remember "DCE and RPC"? well tools would generate the skeletons and user was responsible for filling in the details.

If AI gets you 75% of the way and the humans do verification/testing? That's fine.
 
One of the best programmers I knew told me everything he wrote was never longer than one screenfull of code. It had one job to do and it did it well.
Old school when we were using VT100s and had fixed number of lines and characters so keeping more than that "in physical human memory" was non-trivial.
 
Here's a little tip for learning C or any other programming language. Try closing the laptop lid and writing some of it out with pen and paper, of course you won't be able to compile code you write on paper. You'll find things 'stick' better when written out, at least, I do. A lot of learning is an unconscious or semi-conscious process, it's the way our brains work. There's something about writing code out with pen and paper that is more direct than typing it in on a screen. And autocomplete in an IDE editor is a crutch that prevents you from learning, switch it off and use your brain.
 
Long a go I remember learning C++ via some nice examples, only code, but focused on teaching basics from printing to OOP and other things.

So I will suggest search for some code centric tutorials maybe

* https://learnxinyminutes.com/c
* https://www.cbyexample.com/
* if you like more of a online thing https://exercism.org/tracks/c

I havent checked this, we will need to see if there is good alternative to "rustlings" for C (which kind of feets in exercism like)

* https://github.com/c-lings/clings
* https://github.com/soumichatterjee/C-lings
* https://github.com/ComputerDuck/C-Lings

I bet there are others out there
 
I dunno about the short function rule. Since you now need more functions overall you are introducing more random names for those additional functions which you need to keep in your head. IMHO it is not a clear understandability win.

FreeBSD has many long functions. Some of them are overcooked of course.

You also need all the parameter passing for those new functions, especially when you are not in a class in an OO language (which has other drawbacks). That's a lot of additional text on screen.

If a function is called only in one place it's a trade-off.
 
I like trying to get to 'maximal factorisation'. Only have a single definition of anythng, names, variables, code. |t's that old joke, 'say what you mean and mean what you say'. Or you could say 'minimise or eliminate duplication'. It's a similar process to if you were factorising some equations in maths. Or constructing a deductive system in logic, which is what programming actually is. All your rules should be logically consistent, and not arbitrary. The 'zen of the code' is the 'rule of single definition'.

As an aside, this is why counting klocs as a measure of productivity was always a bad idea, that ends up promoting the worst quality code. It's easy to bump up your klocs count by being a 'copy and paste' programmer. But the best written code will have factorised out the block that is copied and pasted into a function and called it from the multiple locations, however your klocs count will be lower and the boss thinks you've produced less! You can't win (but then, you already knew that 😁 ).
 
As for AI, if some software is writing all the code for you, I don't know how you're ever really going to learn how to program. You can try reading the code it wrote of course, but you'll never really learn until you start writing your own programs, imho. You only really learn by doing it yourself. Of course, the whole point of the AI is to de-skill the job.
 
Introduce a prompt that says something like

Dont write the code for me, instead help me understand about the doubts I have

or ask the llm how to do it itself...

Code:
Act as a senior mentor. Explain the following code/concept without writing new code.

1. Summarize the main goal in one sentence.
2. Explain the high-level logic and why this approach is used.
3. Break down the key components step-by-step.
4. Provide a real-world analogy to make the concept intuitive.
5. Highlight any potential edge cases or performance considerations.

Do not generate any code blocks. Focus entirely on clarity and understanding.

And indeed, I have learn (not expert) more than say 5 programming langs (almost all not functional) doing tutorials and things like that. The other day I asked some LLM help for a new language and I could write the little app, but didnt learn much how to do it myself.

Thihnking like a manager... do a manager ever learn to code just writing what he want to be done without understanding the technical details of the system?
 
Oh wow, a entire backstory
Also TASM? you did programs for MS-DOS or Early Windows? that cool
But your lego thing is actually useful, since C is syntax patterns and i just remember the human brain are wired to find patterns (my bad, everyone)
I will try your suggestions
Thank you :)
MS-DOS mostly. But my biggest assembler little project was bare metal Motorola 6800, I think. It was so long ago...I remember meeting Archimedes once.
 
I would start with BASH or sh, if you want to try native FreeBSD.
> It is useful skill for every level - user - sysadmin - programmer - developer.
> Easy to dish out and test - no compile or libraries or version hell.
> And you can do pretty good stuff with it, you can immediately put to work.
> You can do pretty complex stuff even with poor Windows CMD.
> It has almost all the main programming blocks and it will teach you the fundamentals.
> on top of learning programming, you learn the OS
 
As for AI, if some software is writing all the code for you, I don't know how you're ever really going to learn how to program. You can try reading the code it wrote of course, but you'll never really learn until you start writing your own programs, imho. You only really learn by doing it yourself. Of course, the whole point of the AI is to de-skill the job.
You are right on both counts.
For the de-skilling one. Everyone should know how to program a computer. That said, beyond fundamentals - and those should be understood well, therefore hands on - it is very demanding and niche skill, especially with mounting complexity. I used to be able to dish out my own GUI. Nowadays it is separate discipline with ton of frameworks etc. to learn. Even the wysiwig ones, it has steep learning curve marrying it to your code. And the disadvantage or what I dislike - I don't know precisely how it works.
 
What do you do if it gives you wrong values? Sounds like it could lead to unspecified kinetic results.
This is where long experience and familiarity come into play.

I recently asked AI to give me “hello world” in Win32 ASM.

It was wrong due to no stack cleanup and would have crashed if I ran it.
 
I recently asked AI to give me “hello world” in Win32 ASM.

It was wrong due to no stack cleanup and would have crashed if I ran it.
How could it get that wrong? That's just about the simplest possible thing you could do, a single system call and exit. It sounds crap. And they want to trust it to write avionics flight control systems? You'd better hope the code in your hospital bedside heart-rate monitor, wasn't written by AI.
 
The web gave me this...
I don't have a windows box to assemble it on, so I can't test it.

I've added some comments. To make the win32 version of it, you actually have to make 3 calls to the windows library. It's still about the simplest thing you could do in Win32.
1. get the window handle of the current window
2. call WriteFile() to output the message to the window
3. call ExitProcess() to exit and return the exit code to the caller.

Code:
global _main
; declare the external names in the windows library that we are going to call
    extern  _GetStdHandle@4
    extern  _WriteFile@20
    extern  _ExitProcess@4

; define program section
    section .text
; define main()
_main:
    ; define workspace to receive length written in bytes (output variable)
    ; DWORD  bytes;
    ; set up our stack frame
    mov     ebp, esp
    sub     esp, 4

    ; get handle of current window
    ; hStdOut = GetstdHandle( STD_OUTPUT_HANDLE)
    ; I'm gong to assume the value -11 equates to STD_OUTPUT-HANDLE
    push    -11
    call    _GetStdHandle@4
    ; save the window handle in ebx
    mov     ebx, eax

    ; call WriteFile() to write to stdout on that window handle
    ; WriteFile( hstdOut, message, length(message), &bytes, 0);
    ; push the final parm
    push    0
    ; push the address of the output variable
    lea     eax, [ebp-4]
    push    eax
    ; push the message address and length
    push    (message_end - message)
    push    message
    ; push filehandle
    push    ebx
    ; call writefile()
    call    _WriteFile@20

; exit program with success exit code
    ; ExitProcess(0)
    ; push exit code on stack
    push    0
    ; call exit()
    call    _ExitProcess@4

    ; should never get here, halt this thread if you do
    hlt

; declare and define the string you want to write, the value '10' on the end is the ASCII line feed control character
message:
    db      'Hello, World', 10
message_end:
 
And just for interest here is the freebsd asm version, courtesy of https://www.lemoda.net/assembly/freebsd-hello-world/index.html
Of course this is much simpler because there is no window to deal with, we are simply talking to a unix process stdout filehandle via a single system call.

Code:
        .global _start

.text
_start:
        # write (1, message, 13)
push $13 # Number of bytes
push $message # Address of string to output
push $1 # File handle 1 is stdout
mov     $4, %eax # System call 4 is write
push    %eax
int $0x80

        # exit (0)
push $0 # Exit status
mov     $1, %eax # System call 1 is exit
push    %eax
int $0x80

message:
.ascii  "Hello, world\n"

It's kind of a shame that the forum CODE formatter doesn't include an option for ASM, although it has just about every other language!
 
Back
Top